[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] [patch] Fix for debug/tst-backtrace{5, 6} failure of 32-bit libc on 64-bit host
- To: Paul Pluzhnikov <ppluzhnikov@xxxxxxxxxx>
- Subject: Re: [Patches] [patch] Fix for debug/tst-backtrace{5, 6} failure of 32-bit libc on 64-bit host
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Mon, 20 Feb 2012 23:54:57 +0000 (UTC)
On Mon, 20 Feb 2012, Paul Pluzhnikov wrote:
> debug/tst-backtrace5:
>
> Obtained backtrace with 7 functions
> Function 0: /build32/debug/tst-backtrace5(handle_signal+0x1a) [0x80490ba]
> Function 1: linux-gate.so.1(__kernel_sigreturn+0) [0x55579400]
> Function 2: linux-gate.so.1(__kernel_vsyscall+0x10) [0x55579430]
> Function 3: /build32/libc.so.6(__read+0x23) [0x55657c13]
> Function 4: /build32/debug/tst-backtrace5(fn+0xae) [0x804948e]
> Function 5: /build32/debug/tst-backtrace5(fn+0x1e) [0x80493fe]
> Function 6: /build32/debug/tst-backtrace5(fn+0x1e) [0x80493fe]
> Failure on line 87
>
> I believe above failure is due to the test not accounting for VDSO.
Allowing for vDSO seems sensible there.
> debug/tst-backtrace6:
>
> Obtained backtrace with 7 functions
> Function 0: /build32/debug/tst-backtrace6(handle_signal+0x1a) [0x804910a]
> Function 1: linux-gate.so.1(__kernel_sigreturn+0) [0x55579400]
> Function 2: /build32/debug/tst-backtrace6(noreturn_func+0) [0x80493e0]
> Function 3: /build32/debug/tst-backtrace6() [0x80494d2]
> Function 4: /build32/debug/tst-backtrace6(fn+0x2a) [0x804941a]
> Function 5: /build32/debug/tst-backtrace6(fn+0x2a) [0x804941a]
> Function 6: /build32/debug/tst-backtrace6() [0x80494ef]
> Failure on line 96
>
> This failure is due to GCC laying out fn code like so:
But I don't think the test should be changed here to allow no name for the
function. The libgcc unwinder knows to subtract 1 from a return address
when unwinding (and knows not to do so in a signal frame), and subtracting
1 should get you within the function. Maybe there is somewhere that logic
is missing?
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches