Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: linux-parisc <linux-parisc@vger.kernel.org>,
	John David Anglin <dave.anglin@nrc-cnrc.gc.ca>,
	Carlos O'Donell <carlos@systemhalted.org>,
	Randolph Chung <randolph@tausq.org>
Subject: parisc: unwind tables and backtraces broken?
Date: Mon, 06 Jul 2009 23:58:47 +0200	[thread overview]
Message-ID: <4A527397.7060306@gmx.de> (raw)

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

I started looking into why CONFIG_BACKTRACE_SELF_TEST=y shows uncomplete/wrong/broken backtraces.

To me it seems, that the unwind tables are broken when using newer gcc/binutils versions.
I'm running hppa-linux-gcc (GCC) 4.3.3, and GNU ld (GNU Binutils) 2.19.51.20090704.

hppa-linux-objdump -d vmlinux gives:

vmlinux:     file format elf32-hppa-linux
Disassembly of section .text:
10100000 <stext-0x700>:
10100000:       20 2f e2 06     ldil L%103df000,r1
10100004:       e0 20 28 82     be,n 440(sr4,r1)
10100008:       20 38 42 02     ldil L%10170000,r1
1010000c:       e0 20 23 da     be,n 1ec(sr4,r1)
10100010:       20 32 62 02     ldil L%10165000,r1
10100014:       e0 20 2a 0a     be,n 504(sr4,r1)
10100018:       20 34 42 06     ldil L%10368000,r1
1010001c:       e0 20 27 12     be,n 388(sr4,r1)
10100020:       20 33 f2 04     ldil L%102e7800,r1
10100024:       e0 20 22 ea     be,n 174(sr4,r1)
10100028:       20 35 22 06     ldil L%1032b000,r1
1010002c:       e0 20 2e 2a     be,n 714(sr4,r1)
(and continuing)
I assume this is a jump-table generated by the linker to
resolve long-distance calls?

and later:
         ...
10100700 <stext>:
10100700:       00 00 38 20     mtsp r0,sr4
10100704:       00 00 78 20     mtsp r0,sr5
10100708:       00 00 b8 20     mtsp r0,sr6
1010070c:       00 00 f8 20     mtsp r0,sr7
10100710:       20 69 80 0c     ldil L%692000,r3
10100714:       34 63 00 00     ldo 0(r3),r3
10100718:       20 93 f0 0c     ldil L%6e7800,r4
1010071c:       34 84 0f 58     ldo 7ac(r4),r4
10100720 <$bss_loop>:
10100720:       80 83 9f f7     cmpb,<<,n r3,r4,10100720 <$bss_loop>
10100724:       0c 60 12 a8     stw,ma r0,4(r3)
....

but the unwind table when running the kernel with the attached patch (see below) shows:
...
unwind_init: start = 0x105fb3c0, end = 0x10634f30, entries = 14775
unwind 1: 100ff900 - 100ffa80, len=385
unwind 2: 100ffa84 - 100ffad4, len=81
unwind 3: 100ffad8 - 100ffb2c, len=85
unwind 4: 100ffb30 - 100ffbc8, len=153
unwind 5: 100ffbcc - 100ffc38, len=109
unwind 6: 100ffc3c - 100ffc9c, len=97
unwind 7: 100ffca0 - 100ffd00, len=97
unwind 8: 100ffd04 - 100ffd64, len=97
unwind 9: 100ffd68 - 100ffdc8, len=97
unwind 10: 100ffdcc - 100ffdec, len=33

 From this table I don't even understand the values of the very first
entry (unwind 1: 100ff900 - 100ffa80).
This does not resolve to any entry in the assembly.

My assumption:
When the linker creates the long-distance jump table, it does not adjusts
the values in the unwind table.
Second, when the linker discards attribute-weak functions,
it doesn't deletes/adjusts the unwind table entries of the deleted functions either.

Question: Might my analysis be correct?

Helge

[-- Attachment #2: dump-unwind-table.diff --]
[-- Type: text/x-patch, Size: 905 bytes --]

diff --git a/arch/parisc/kernel/unwind.c b/arch/parisc/kernel/unwind.c
index 69dad5a..d7c7241 100644
--- a/arch/parisc/kernel/unwind.c
+++ b/arch/parisc/kernel/unwind.c
@@ -94,6 +94,10 @@ unwind_table_init(struct unwind_table *table, const char *name,
 	struct unwind_table_entry *start = table_start;
 	struct unwind_table_entry *end = 
 		(struct unwind_table_entry *)table_end - 1;
+	int nr = 0;
+
+	extern void stext();
+	// base_addr += ((unsigned long)&stext) - KERNEL_START; // HELGE
 
 	table->name = name;
 	table->base_addr = base_addr;
@@ -112,6 +116,15 @@ unwind_table_init(struct unwind_table *table, const char *name,
 
 		start->region_start += base_addr;
 		start->region_end += base_addr;
+		if (nr<10) {
+			nr++;
+			printk("unwind %d: %x - %x, len=%d\n",
+				nr,
+				start->region_start,
+				start->region_end,
+				start->region_end - start->region_start + 1);
+				
+		}
 	}
 }
 

             reply	other threads:[~2009-07-06 21:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-06 21:58 Helge Deller [this message]
2009-07-07  0:50 ` parisc: unwind tables and backtraces broken? John David Anglin
2009-07-07  3:07   ` Randolph Chung
2009-07-07  4:42     ` Kyle McMartin
2009-07-07 14:07       ` Carlos O'Donell
2009-07-07 18:02         ` Helge Deller
2009-07-07  2:57 ` Randolph Chung
2009-07-07 18:01   ` Helge Deller
2009-07-07 18:33     ` John David Anglin
2009-07-07 20:36       ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A527397.7060306@gmx.de \
    --to=deller@gmx.de \
    --cc=carlos@systemhalted.org \
    --cc=dave.anglin@nrc-cnrc.gc.ca \
    --cc=linux-parisc@vger.kernel.org \
    --cc=randolph@tausq.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox