[PATCH] CONFIG_UNWIND_INFO

[PATCH] CONFIG_UNWIND_INFO

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

As a foundation for reliable stack unwinding, this adds a config option
(available to all architectures except IA64) to enable the generation
of frame unwind information.

From: Jan Beulich <jbeulich@novell.com>

(actual patch attached)


[-- Attachment #2: linux-2.6.14-unwind-info.patch --]
[-- Type: application/octet-stream, Size: 1424 bytes --]

As a foundation for reliable stack unwinding, this adds a config option
(available to all architectures except IA64) to enable the generation
of frame unwind information.

From: Jan Beulich <jbeulich@novell.com>

--- 2.6.14/Makefile	2005-10-28 02:02:08.000000000 +0200
+++ 2.6.14-unwind-info/Makefile	2005-11-04 16:20:57.000000000 +0100
@@ -517,6 +517,10 @@ CFLAGS		+= $(call add-align,CONFIG_CC_AL
 CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
 CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
 
+ifdef CONFIG_UNWIND_INFO
+CFLAGS		+= -fasynchronous-unwind-tables
+endif
+
 ifdef CONFIG_FRAME_POINTER
 CFLAGS		+= -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)
 else
--- 2.6.14/lib/Kconfig.debug	2005-10-28 02:02:08.000000000 +0200
+++ 2.6.14-unwind-info/lib/Kconfig.debug	2005-11-08 10:36:39.000000000 +0100
@@ -178,3 +178,12 @@ config FRAME_POINTER
 	  on some architectures or you use external debuggers.
 	  If you don't debug the kernel, you can say N.
 
+config UNWIND_INFO
+	bool "Compile the kernel with frame unwind information"
+	depends on !IA64
+	default DEBUG_KERNEL
+	help
+	  If you say Y here the resulting kernel image will be slightly larger
+	  but not slower, and it will give very useful debugging information.
+	  If you don't debug the kernel, you can say N, but we may not be able
+	  to solve problems without frame unwind information or frame pointers.

Re: [PATCH] CONFIG_UNWIND_INFO

[Andrew Morton]

"Jan Beulich" <JBeulich@novell.com> wrote:
>
> As a foundation for reliable stack unwinding, this adds a config option
> (available to all architectures except IA64) to enable the generation
> of frame unwind information.
> 

This breaks ppc64.

> Index: linux/Makefile
> ===================================================================
> --- linux.orig/Makefile
> +++ linux/Makefile
> @@ -502,6 +502,10 @@ CFLAGS		+= $(call add-align,CONFIG_CC_AL
>  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
>  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
>  
> +ifdef CONFIG_UNWIND_INFO
> +CFLAGS		+= -fasynchronous-unwind-tables
> +endif
> +
>  ifdef CONFIG_FRAME_POINTER
>  CFLAGS		+= -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,)
>  else
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -195,6 +195,16 @@ config FRAME_POINTER
>  	  some architectures or if you use external debuggers.
>  	  If you don't debug the kernel, you can say N.
>  
> +config UNWIND_INFO
> +	bool "Compile the kernel with frame unwind information"
> +	depends on !IA64
> +	default DEBUG_KERNEL
> +	help
> +	  If you say Y here the resulting kernel image will be slightly larger
> +	  but not slower, and it will give very useful debugging information.
> +	  If you don't debug the kernel, you can say N, but we may not be able
> +	  to solve problems without frame unwind information or frame pointers.
> +
>  config RCU_TORTURE_TEST
>  	tristate "torture tests for RCU"
>  	depends on DEBUG_KERNEL
> 

If you do a `make oldconfig' with CONFIG_DEBUG_KERNEL you get
-fasynchronous-unwind-tables and (on my yellowdog-4 toolchain at least) the
ppc64 kernel doesn't like that one bit. 


EXT3-fs: mounted filesystem with ordered data mode.
ADDRCONF(NETDEV_UP): eth0: link is not ready
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is off for TX and off for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
autofs: Unknown ADD relocation: 44
sunrpc: Unknown ADD relocation: 44
lockd: Unknown symbol svc_recv
lockd: Unknown symbol svc_create
lockd: Unknown symbol rpciod_up
lockd: Unknown symbol rpc_destroy_client
lockd: Unknown symbol xdr_encode_netobj
lockd: Unknown symbol svc_destroy
lockd: Unknown symbol xprt_create_proto
lockd: Unknown symbol rpc_delay
lockd: Unknown symbol rpc_call_async
lockd: Unknown symbol rpc_create_client
lockd: Unknown symbol svc_makesock
lockd: Unknown symbol nlm_debug
lockd: Unknown symbol xdr_decode_netobj
lockd: Unknown symbol svc_wake_up
lockd: Unknown symbol rpc_force_rebind
lockd: Unknown symbol rpciod_down
lockd: Unknown symbol svc_exit_thread
lockd: Unknown symbol xdr_encode_string
lockd: Unknown symbol rpc_call_sync
lockd: Unknown symbol xdr_decode_string_inplace
lockd: Unknown symbol svc_set_client
lockd: Unknown symbol svc_process
lockd: Unknown symbol xprt_set_timeout
lockd: Unknown symbol rpc_restart_call
lockd: Unknown symbol svc_create_thread
exportfs: Unknown ADD relocation: 44
sunrpc: Unknown ADD relocation: 44
lockd: Unknown symbol svc_recv
lockd: Unknown symbol svc_create
lockd: Unknown symbol rpciod_up
lockd: Unknown symbol rpc_destroy_client

I fixed it up for now by sticking an `&& !PPC64' in there, but why did it
break, and what other architectures/toolchains broke?

Re: [PATCH] CONFIG_UNWIND_INFO

[Sam Ravnborg]

On Sat, Jan 14, 2006 at 04:56:35AM -0800, Andrew Morton wrote:
> 
> > Index: linux/Makefile
> > ===================================================================
> > --- linux.orig/Makefile
> > +++ linux/Makefile
> > @@ -502,6 +502,10 @@ CFLAGS		+= $(call add-align,CONFIG_CC_AL
> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
> >  
> > +ifdef CONFIG_UNWIND_INFO
> > +CFLAGS		+= -fasynchronous-unwind-tables
> > +endif
Is this option available on all gcc's for all archs?
Otherwise you have to do:
CFLAGS		+= $(call cc-option,-fasynchronous-unwind-tables,)

	Sam

Re: [PATCH] CONFIG_UNWIND_INFO

[Jan Beulich]

>>> Sam Ravnborg <sam@ravnborg.org> 14.01.06 15:03:01 >>>
>On Sat, Jan 14, 2006 at 04:56:35AM -0800, Andrew Morton wrote:
>> 
>> > Index: linux/Makefile
>> > ===================================================================
>> > --- linux.orig/Makefile
>> > +++ linux/Makefile
>> > @@ -502,6 +502,10 @@ CFLAGS		+= $(call add-align,CONFIG_CC_AL
>> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
>> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
>> >  
>> > +ifdef CONFIG_UNWIND_INFO
>> > +CFLAGS		+= -fasynchronous-unwind-tables
>> > +endif
>Is this option available on all gcc's for all archs?
>Otherwise you have to do:
>CFLAGS		+= $(call cc-option,-fasynchronous-unwind-tables,)

Yes, it is (and it has been at least since 3.2.x). Apparently the PPC backend doesn't fully support this...

Jan

Re: [PATCH] CONFIG_UNWIND_INFO

[Andrew Morton]

"Jan Beulich" <JBeulich@novell.com> wrote:
>
> >>> Sam Ravnborg <sam@ravnborg.org> 14.01.06 15:03:01 >>>
> >On Sat, Jan 14, 2006 at 04:56:35AM -0800, Andrew Morton wrote:
> >> 
> >> > Index: linux/Makefile
> >> > ===================================================================
> >> > --- linux.orig/Makefile
> >> > +++ linux/Makefile
> >> > @@ -502,6 +502,10 @@ CFLAGS		+= $(call add-align,CONFIG_CC_AL
> >> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_LOOPS,-loops)
> >> >  CFLAGS		+= $(call add-align,CONFIG_CC_ALIGN_JUMPS,-jumps)
> >> >  
> >> > +ifdef CONFIG_UNWIND_INFO
> >> > +CFLAGS		+= -fasynchronous-unwind-tables
> >> > +endif
> >Is this option available on all gcc's for all archs?
> >Otherwise you have to do:
> >CFLAGS		+= $(call cc-option,-fasynchronous-unwind-tables,)
> 
> Yes, it is (and it has been at least since 3.2.x). Apparently the PPC backend doesn't fully support this...
> 

And others might not support it either.  We don't know.

Perhaps this option should be enabled only on architectures where it's known
to work, rather than disabled only on ppc64, as my fix does.

Re: [PATCH] CONFIG_UNWIND_INFO

[Paul Mackerras]

Andrew Morton writes:

> If you do a `make oldconfig' with CONFIG_DEBUG_KERNEL you get
> -fasynchronous-unwind-tables and (on my yellowdog-4 toolchain at least) the
> ppc64 kernel doesn't like that one bit. 
> 
> 
> EXT3-fs: mounted filesystem with ordered data mode.
> ADDRCONF(NETDEV_UP): eth0: link is not ready
> tg3: eth0: Link is up at 100 Mbps, full duplex.
> tg3: eth0: Flow control is off for TX and off for RX.
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> autofs: Unknown ADD relocation: 44
> sunrpc: Unknown ADD relocation: 44

We aren't handling R_PPC64_REL64 relocations in our module code.  This
patch (completely untested :) might help.

Paul.

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 928b858..4885f39 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -337,6 +337,10 @@ int apply_relocate_add(Elf64_Shdr *sechd
 			*(unsigned long *)location = value;
 			break;
 
+		case R_PPC64_REL64:
+			*location = value - (unsigned long) location;
+			break;
+
 		case R_PPC64_TOC:
 			*(unsigned long *)location = my_r2(sechdrs, me);
 			break;

Re: [PATCH] CONFIG_UNWIND_INFO

[Andi Kleen]

On Wed, Jan 18, 2006 at 10:48:57PM +1100, Paul Mackerras wrote:
> Andrew Morton writes:
> 
> > If you do a `make oldconfig' with CONFIG_DEBUG_KERNEL you get
> > -fasynchronous-unwind-tables and (on my yellowdog-4 toolchain at least) the
> > ppc64 kernel doesn't like that one bit. 
> > 
> > 
> > EXT3-fs: mounted filesystem with ordered data mode.
> > ADDRCONF(NETDEV_UP): eth0: link is not ready
> > tg3: eth0: Link is up at 100 Mbps, full duplex.
> > tg3: eth0: Flow control is off for TX and off for RX.
> > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > autofs: Unknown ADD relocation: 44
> > sunrpc: Unknown ADD relocation: 44
> 
> We aren't handling R_PPC64_REL64 relocations in our module code.  This
> patch (completely untested :) might help.

The module loader should be discarding these sections on most architectures
because there is nothing that needs them and it's just a waste of memory
to store them.

[IA64 might be an exception because they have a kernel level unwinder]

So it would be best to change the module loader to do this I guess.

-Andi

Re: [PATCH] CONFIG_UNWIND_INFO

[Jan Beulich]

>The module loader should be discarding these sections on most architectures
>because there is nothing that needs them and it's just a waste of memory
>to store them.
>
>[IA64 might be an exception because they have a kernel level unwinder]
>
>So it would be best to change the module loader to do this I guess.

But that's why this is a config option: You can prevent the data from being created in the first place if you know you
won't need it. For nlkd, adding code to discard these sections despite CONFIG_UNWIND_INFO would only make for more
differences, because I'd then have to undo this discarding.

Jan

Re: [PATCH] CONFIG_UNWIND_INFO

[Andi Kleen]

On Wednesday 18 January 2006 16:58, Jan Beulich wrote:
> >The module loader should be discarding these sections on most architectures
> >because there is nothing that needs them and it's just a waste of memory
> >to store them.
> >
> >[IA64 might be an exception because they have a kernel level unwinder]
> >
> >So it would be best to change the module loader to do this I guess.
> 
> But that's why this is a config option: You can prevent the data from being created in the first place if you know you
> won't need it. 

The usual use case is that you only need it on disk for your gdb,
but not in RAM. And it now even causes problems like the missing
relocations on PPC64.

[Yes NLKD is not "usual" right now, sorry]

At some point it will change for x86-64 at least when the NLKD unwinder
is ported into the kernel (which I plan to do), but even then it won't
be needed for majority of architectures. Since IA64 likely will need
an exception mechanism for this anyways x86-64 could then later use it too.

> For nlkd, adding code to discard these sections despite CONFIG_UNWIND_INFO would only make for more 
> differences, because I'd then have to undo this discarding.

The interests of in tree usage normally beats caring for out of tree
patches.

-Andi

Re: [PATCH] CONFIG_UNWIND_INFO

[Jan Beulich]

>The usual use case is that you only need it on disk for your gdb,
>but not in RAM.

If you care about gdb, you'd be building with CONFIG_DEBUG_INFO anyway, and get the same information in .debug_frames
(which already is a noload section) without the need to enable CONFIG_UNWIND_INFO.

Jan

Re: [PATCH] CONFIG_UNWIND_INFO

[Paul Mackerras]

Andi Kleen writes:

> The module loader should be discarding these sections on most architectures
> because there is nothing that needs them and it's just a waste of memory
> to store them.

Apparently the module loader loads all sections marked SHF_ALLOC,
reasonably enough.

Why would we want the unwind tables in the .ko but not in kernel
memory?  Isn't the point of this so that we can add an in-kernel
unwinder?

Paul.

Re: [PATCH] CONFIG_UNWIND_INFO

[Andi Kleen]

On Fri, Jan 20, 2006 at 03:47:09PM +1100, Paul Mackerras wrote:
> Andi Kleen writes:
> 
> > The module loader should be discarding these sections on most architectures
> > because there is nothing that needs them and it's just a waste of memory
> > to store them.
> 
> Apparently the module loader loads all sections marked SHF_ALLOC,
> reasonably enough.
> 
> Why would we want the unwind tables in the .ko but not in kernel
> memory?  Isn't the point of this so that we can add an in-kernel
> unwinder?

For most people so far it was for kgdb where they would be needed
on disk only.

-Andi