Skip to contentSkip to conversation

CONFIG_UNWIND_INFO

PATCH In review Jan Beulich 6 participants 12 messages Nov 8, 2005 – Jan 20, 2006

Subsystems (3)
PowerPC Kbuild Library code
lore
Share & tools
lore

Jan Beulich

author
#0 lore raw

PATCH 1/1 CONFIG_UNWIND_INFO

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 <[email protected]>

(actual patch attached)

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 <[email protected]>

Makefile +4 -0
@@ -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
lib/Kconfig.debug +9 -0
@@ -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.
#1 lore raw
Quoted 5 lines · Jan Beulich

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.

Quoted 27 lines

Index: linux/Makefile
===================================================================

Makefile +4 -0
@@ -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
===================================================================

lib/Kconfig.debug +3 -0
@@ -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

lib/Kconfig.debug config FRAME_POINTER · line 210

Quoted 10 lines
lib/Kconfig.debug +7 -0
+	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?

#2 lore raw
Quoted 9 lines · Andrew Morton
Quoted 9 lines

Index: linux/Makefile
===================================================================

Makefile +0 -0
@@ -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)
Quoted 3 lines

Makefile CFLAGS += $(call add-align,CONFIG_CC_AL · line 522

Quoted 3 lines
Makefile +3 -0
+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

author
#3 lore raw
Quoted 11 lines
Quoted 1 line
Quoted 1 line

Sam Ravnborg <[email protected]> 14.01.06 15:03:01 >>>

Quoted 9 lines · Andrew Morton
Quoted 9 lines

Index: linux/Makefile
===================================================================

Makefile +0 -0
@@ -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)
Quoted 6 lines
Quoted 3 lines

Makefile CFLAGS += $(call add-align,CONFIG_CC_AL · line 522

Quoted 3 lines
Makefile +3 -0
+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

#4 lore raw
Quoted 12 lines · Jan Beulich
Quoted 12 lines
Quoted 2 lines
Quoted 2 lines

Sam Ravnborg <[email protected]> 14.01.06 15:03:01 >>>

Quoted 9 lines · Andrew Morton
Quoted 9 lines

Index: linux/Makefile
===================================================================

Makefile +0 -0
@@ -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)
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines

Makefile CFLAGS += $(call add-align,CONFIG_CC_AL · line 522

Quoted 3 lines
Makefile +3 -0
+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.

#5 lore raw
In reply to Andrew Morton
Quoted 5 lines · Andrew Morton

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.

Quoted 7 lines

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.

arch/powerpc/kernel/module_64.c +4 -0
index 928b858..4885f39 100644
@@ -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;
#6 lore raw
Quoted 15 lines · Paul Mackerras
Quoted 5 lines · Andrew Morton

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.

Quoted 7 lines

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

Quoted 2 lines

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

author
#7 lore raw
Quoted 7 lines

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

#8 lore raw
Quoted 10 lines · Jan Beulich
Quoted 7 lines

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.

Quoted 2 lines

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

author
#9 lore raw
Quoted 2 lines

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

#10 lore raw
In reply to Andi Kleen
Quoted 3 lines · Andi Kleen

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.

#11 lore raw
Quoted 6 lines · Paul Mackerras
Quoted 3 lines · Andi Kleen

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.

Quoted 6 lines

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