On 07/07/2009 04:57 AM, Randolph Chung wrote:
Helge,
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.
I am a little fuzzy on the details, but the numbers printed above are
what is stored in the unwind table. This does not correspond with the
actual address in memory, which is adjusted by an offset. In the case of
kernel symbols, this offset is KERNEL_START (this is a parameter passed
to unwind_table_init()
The addresses given above already got the offset added. They are wrong
nevertheless.
My assumption:
When the linker creates the long-distance jump table, it does not adjusts
the values in the unwind table.
this used to work.....
Yes.
Interestingly, this problem showed up to me now since I updated my 32- and
64bit crosscompilers to 4.3.3 (and binutils of course).
I used (on 32bit) the gcc-3.3 before and this one doesn't exibited the
problem of buggy unwind tables (with the existing/same kernel source code).
Second, when the linker discards attribute-weak functions,
it doesn't deletes/adjusts the unwind table entries of the deleted
functions either.
can you try this with a userspace program? gdb uses this same unwind
information to do backtraces. if the unwind info is wrong gdb will be
very broken.
I'll try, but I assume userspace is ok. If it wouldn't be, Dave probably
won't be able to debug the other userspace issues (the segv-thread on debian's
buildds).
On the other hand, the kernel does use a more complex linker script so
it is possible that some options in the linker script is triggering some
bug.
Yes, maybe. But again, I think gcc-3.3 (and the old binutils) could handle this gracefully.
Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
