parisc: fix unwind with recent gcc versions
PATCH 1/1 parisc: fix unwind with recent gcc versions
From: Helge Deller <[email protected]>
kernel unwinding is broken with gcc >= 4.x. Part of the problem is, that binutils seems sensible where the unwind information is stored.
--- arch/parisc/kernel/unwind.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
arch/parisc/kernel/unwind.c +1 -1
@@ -28,7 +28,7 @@ #define dbg(x...)#endif -#define KERNEL_START (KERNEL_BINARY_TEXT_START - 0x1000) +#define KERNEL_START (KERNEL_BINARY_TEXT_START)extern struct unwind_table_entry __start___unwind[];extern struct unwind_table_entry __stop___unwind[];
arch/parisc/kernel/vmlinux.lds.S +0 -1
@@ -78,9 +78,6 @@ SECTIONS */ . = ALIGN(PAGE_SIZE); data_start = .; - EXCEPTION_TABLE(16)
Quoted 5 lines · Kyle McMartin
From: Helge Deller <[email protected]>
kernel unwinding is broken with gcc >= 4.x. Part of the problem is, that binutils seems sensible where the unwind information is stored.
The commentary doesn't seem to make much sense to me. Do you mean "sensitive" rather than "sensible"? And is it an actual binutils bug, or what?
Also, are the PARISC people 100% sure that you really want unwinding in the first place? We got rid of it as being terminally broken on x86, because tools and asm always got it wrong, and special things like irq frames etc continually broke it in the most annoying ways possible (ie WARN_ON() statements became fatal oopses due to unwind errors etc).
Having a tentative and unreliable stack trace is generally better than a totally broken one.
Linus
Helge Deller
maintainerQuoted 10 lines · Linus Torvalds
Quoted 5 lines · Kyle McMartin
From: Helge Deller<[email protected]>
kernel unwinding is broken with gcc>= 4.x. Part of the problem is, that binutils seems sensible where the unwind information is stored.
The commentary doesn't seem to make much sense to me. Do you mean "sensitive" rather than "sensible"? And is it an actual binutils bug, or what?
Yes, sorry, I meant "sensitive".
It's a combination of lots of things. Newer gcc, with newer binutils and all latest changes to our parisc arch/parisc/kernel/vmlinux.lds.S linker script, e.g.:
commit ab635e7d499f23a5791e69e2ebbc9a40c9983d89
Author: Tim Abbott <[email protected]> Date: Thu Sep 24 10:36:18 2009 -0400
parisc: Remove useless altinstructions code copied from x86.
commit 57a8e1161e1a944823542138e61dd8f38fd9b9e8
Author: Tim Abbott <[email protected]> Date: Thu Sep 24 10:36:17 2009 -0400
parisc: Clean up linker script using new linker script macros.
commit 023bf6f1b8bf58dc4da7f0dc1cf4787b0d5297c1
Author: Tejun Heo <[email protected]> Date: Thu Jul 9 11:27:40 2009 +0900
linker script: unify usage of discard definition
commit 405d967dc70002991f8fc35c20e0d3cbc7614f63
Author: Tejun Heo <[email protected]> Date: Wed Jun 24 15:13:38 2009 +0900
linker script: throw away .discard section
All those patches (which are basically OK), triggers a new layout location for our unwind tables and as such broke our existing unwinding.
My patch basically just gets it right again.
Quoted 2 lines
Also, are the PARISC people 100% sure that you really want unwinding in the first place?
No, but it's the only and best thing we have available right now. There have been discussions about other options like dwarf and similiar though:
http://marc.info/?l=linux-parisc&m=124694174008515&w=2
Quoted 6 lines
We got rid of it as being terminally broken on x86,
because tools and asm always got it wrong, and special things like irq frames etc continually broke it in the most annoying ways possible (ieWARN_ON()statements became fatal oopses due to unwind errors etc). Having a tentative and unreliable stack trace is generally better than a totally broken one.
Yes we had oopses as well. Current code tries hard to not unwind outside of the kernel text segment. This fixed most issues and in the past weeks I didn't faced any other problems with unwinding (which doesn't mean there aren't any other problems left).
Helge
James Bottomley
maintainerQuoted 8 lines · Linus Torvalds
Also, are the PARISC people 100% sure that you really want unwinding in the first place? We got rid of it as being terminally broken on x86, because tools and asm always got it wrong, and special things like irq frames etc continually broke it in the most annoying ways possible (ie
WARN_ON()statements became fatal oopses due to unwind errors etc).Having a tentative and unreliable stack trace is generally better than a totally broken one.
Being a risc system, we don't have a lot of choice. returns on parisc are conventionally jump through register two, so without unwind information we have no idea where in the stack frame (or even if) they're stored. Our other problem is that our stack frames have a predefined size which often doesn't get fully filled, so the stack gets gummed up with a lot of cruft from previous calls; thus even if we just trawl it for relevant addresses, we get a lot of bogus information.
Look at it this way: our unwind information has to be correct otherwise the debugger would continually fail on the platform, so the tool chain has an incentive to get it right.
James