* [PATCH] parisc: fix unwind with recent gcc versions
@ 2009-11-28 20:33 Kyle McMartin
2009-11-29 17:34 ` Linus Torvalds
0 siblings, 1 reply; 4+ messages in thread
From: Kyle McMartin @ 2009-11-28 20:33 UTC (permalink / raw)
To: torvalds; +Cc: deller, linux-parisc
From: Helge Deller <deller@gmx.de>
kernel unwinding is broken with gcc >= 4.x. Part of the problem is, that
binutils seems sensible where the unwind information is stored.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
---
arch/parisc/kernel/unwind.c | 2 +-
arch/parisc/kernel/vmlinux.lds.S | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/parisc/kernel/unwind.c b/arch/parisc/kernel/unwind.c
index 69dad5a..a36799e 100644
--- a/arch/parisc/kernel/unwind.c
+++ b/arch/parisc/kernel/unwind.c
@@ -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[];
diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S
index fda4baa..9dab4a4 100644
--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -78,9 +78,6 @@ SECTIONS
*/
. = ALIGN(PAGE_SIZE);
data_start = .;
- EXCEPTION_TABLE(16)
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] parisc: fix unwind with recent gcc versions
2009-11-28 20:33 [PATCH] parisc: fix unwind with recent gcc versions Kyle McMartin
@ 2009-11-29 17:34 ` Linus Torvalds
2009-11-29 20:23 ` Helge Deller
2009-11-30 14:14 ` James Bottomley
0 siblings, 2 replies; 4+ messages in thread
From: Linus Torvalds @ 2009-11-29 17:34 UTC (permalink / raw)
To: kyle; +Cc: deller, linux-parisc
On Sat, 28 Nov 2009, Kyle McMartin wrote:
>
> From: Helge Deller <deller@gmx.de>
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] parisc: fix unwind with recent gcc versions
2009-11-29 17:34 ` Linus Torvalds
@ 2009-11-29 20:23 ` Helge Deller
2009-11-30 14:14 ` James Bottomley
1 sibling, 0 replies; 4+ messages in thread
From: Helge Deller @ 2009-11-29 20:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: kyle, linux-parisc
On 11/29/2009 06:34 PM, Linus Torvalds wrote:
> On Sat, 28 Nov 2009, Kyle McMartin wrote:
>>
>> From: Helge Deller<deller@gmx.de>
>>
>> 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 <tabbott@ksplice.com>
Date: Thu Sep 24 10:36:18 2009 -0400
parisc: Remove useless altinstructions code copied from x86.
commit 57a8e1161e1a944823542138e61dd8f38fd9b9e8
Author: Tim Abbott <tabbott@ksplice.com>
Date: Thu Sep 24 10:36:17 2009 -0400
parisc: Clean up linker script using new linker script macros.
commit 023bf6f1b8bf58dc4da7f0dc1cf4787b0d5297c1
Author: Tejun Heo <tj@kernel.org>
Date: Thu Jul 9 11:27:40 2009 +0900
linker script: unify usage of discard definition
commit 405d967dc70002991f8fc35c20e0d3cbc7614f63
Author: Tejun Heo <tj@kernel.org>
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.
> 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
>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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] parisc: fix unwind with recent gcc versions
2009-11-29 17:34 ` Linus Torvalds
2009-11-29 20:23 ` Helge Deller
@ 2009-11-30 14:14 ` James Bottomley
1 sibling, 0 replies; 4+ messages in thread
From: James Bottomley @ 2009-11-30 14:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: kyle, deller, linux-parisc
On Sun, 2009-11-29 at 09:34 -0800, Linus Torvalds wrote:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-11-30 14:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-28 20:33 [PATCH] parisc: fix unwind with recent gcc versions Kyle McMartin
2009-11-29 17:34 ` Linus Torvalds
2009-11-29 20:23 ` Helge Deller
2009-11-30 14:14 ` James Bottomley
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).