* [PATCH] CONFIG_UNWIND_INFO
@ 2005-11-08 12:59 Jan Beulich
2006-01-14 12:56 ` Andrew Morton
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2005-11-08 12:59 UTC (permalink / raw)
To: linux-kernel
[-- 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2005-11-08 12:59 [PATCH] CONFIG_UNWIND_INFO Jan Beulich
@ 2006-01-14 12:56 ` Andrew Morton
2006-01-14 14:03 ` Sam Ravnborg
2006-01-18 11:48 ` Paul Mackerras
0 siblings, 2 replies; 12+ messages in thread
From: Andrew Morton @ 2006-01-14 12:56 UTC (permalink / raw)
To: Jan Beulich
Cc: linux-kernel, Andi Kleen, Paul Mackerras, Benjamin Herrenschmidt
"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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-14 12:56 ` Andrew Morton
@ 2006-01-14 14:03 ` Sam Ravnborg
2006-01-16 7:36 ` Jan Beulich
2006-01-18 11:48 ` Paul Mackerras
1 sibling, 1 reply; 12+ messages in thread
From: Sam Ravnborg @ 2006-01-14 14:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Jan Beulich, linux-kernel, Andi Kleen, Paul Mackerras,
Benjamin Herrenschmidt
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-14 14:03 ` Sam Ravnborg
@ 2006-01-16 7:36 ` Jan Beulich
2006-01-16 7:46 ` Andrew Morton
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2006-01-16 7:36 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Benjamin Herrenschmidt, Andi Kleen, Andrew Morton,
Paul Mackerras, linux-kernel
>>> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-16 7:36 ` Jan Beulich
@ 2006-01-16 7:46 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2006-01-16 7:46 UTC (permalink / raw)
To: Jan Beulich; +Cc: sam, benh, ak, paulus, linux-kernel
"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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-14 12:56 ` Andrew Morton
2006-01-14 14:03 ` Sam Ravnborg
@ 2006-01-18 11:48 ` Paul Mackerras
2006-01-18 15:18 ` Andi Kleen
1 sibling, 1 reply; 12+ messages in thread
From: Paul Mackerras @ 2006-01-18 11:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Jan Beulich, linux-kernel, Andi Kleen, Benjamin Herrenschmidt
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;
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-18 11:48 ` Paul Mackerras
@ 2006-01-18 15:18 ` Andi Kleen
2006-01-18 15:58 ` Jan Beulich
2006-01-20 4:47 ` Paul Mackerras
0 siblings, 2 replies; 12+ messages in thread
From: Andi Kleen @ 2006-01-18 15:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: Andrew Morton, Jan Beulich, linux-kernel, Benjamin Herrenschmidt,
tony.luck
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-18 15:18 ` Andi Kleen
@ 2006-01-18 15:58 ` Jan Beulich
2006-01-18 16:11 ` Andi Kleen
2006-01-20 4:47 ` Paul Mackerras
1 sibling, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2006-01-18 15:58 UTC (permalink / raw)
To: Andreas Kleen
Cc: tony.luck, Benjamin Herrenschmidt, Andrew Morton, Paul Mackerras,
linux-kernel
>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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-18 15:58 ` Jan Beulich
@ 2006-01-18 16:11 ` Andi Kleen
2006-01-18 16:48 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Andi Kleen @ 2006-01-18 16:11 UTC (permalink / raw)
To: Jan Beulich
Cc: tony.luck, Benjamin Herrenschmidt, Andrew Morton, Paul Mackerras,
linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-18 16:11 ` Andi Kleen
@ 2006-01-18 16:48 ` Jan Beulich
0 siblings, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2006-01-18 16:48 UTC (permalink / raw)
To: Andi Kleen
Cc: tony.luck, Benjamin Herrenschmidt, Andrew Morton, Paul Mackerras,
linux-kernel
>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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-18 15:18 ` Andi Kleen
2006-01-18 15:58 ` Jan Beulich
@ 2006-01-20 4:47 ` Paul Mackerras
2006-01-20 6:13 ` Andi Kleen
1 sibling, 1 reply; 12+ messages in thread
From: Paul Mackerras @ 2006-01-20 4:47 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, Jan Beulich, linux-kernel, Benjamin Herrenschmidt,
tony.luck
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] CONFIG_UNWIND_INFO
2006-01-20 4:47 ` Paul Mackerras
@ 2006-01-20 6:13 ` Andi Kleen
0 siblings, 0 replies; 12+ messages in thread
From: Andi Kleen @ 2006-01-20 6:13 UTC (permalink / raw)
To: Paul Mackerras
Cc: Andrew Morton, Jan Beulich, linux-kernel, Benjamin Herrenschmidt,
tony.luck
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-01-20 6:14 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-08 12:59 [PATCH] CONFIG_UNWIND_INFO Jan Beulich
2006-01-14 12:56 ` Andrew Morton
2006-01-14 14:03 ` Sam Ravnborg
2006-01-16 7:36 ` Jan Beulich
2006-01-16 7:46 ` Andrew Morton
2006-01-18 11:48 ` Paul Mackerras
2006-01-18 15:18 ` Andi Kleen
2006-01-18 15:58 ` Jan Beulich
2006-01-18 16:11 ` Andi Kleen
2006-01-18 16:48 ` Jan Beulich
2006-01-20 4:47 ` Paul Mackerras
2006-01-20 6:13 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).