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);
+
+ }
}
}
next 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