I'm seeing a problem on both 2.6.37 and 3.3 MIPS kernels where I can't
unwind through a MIPS signal frame. It looks like this is caused by
the VDSO code that was added 2/2010. When the unwinder tries to find
the frame info for the caller of the signal handler (the trampoline in
VDSO), it can't find the eh_frame info because the address is in the
VDSO area and stops unwinding. It looks like other platforms solve
this by adding the eh_frame info for the VDSO area so the lookup
works.
This problem ends up breaking pthread cleanup for C++ programs because
the cleanup is done using a class with the expectation that the
destructor will be called when the thread gets canceled by a cancel
signal. This seems like a big problem for all current MIPS kernels so
I was wondering if I'm missing something?
If this is correct, then it seems like the best solution would be to
add the VDSO eh_frame info to MIPS.
Thanks
Al Cooper
On Sat, Feb 18, 2012 at 5:13 AM, Alan Cooper <[email protected]> wrote:
> This problem ends up breaking pthread cleanup for C++ programs because
> the cleanup is done using a class with the expectation that the
> destructor will be called when the thread gets canceled by a cancel
> signal. This seems like a big problem for all current MIPS kernels so
> I was wondering if I'm missing something?
>
> If this is correct, then it seems like the best solution would be to
> add the VDSO eh_frame info to MIPS.
>
Feel free to send a patch after testing;)
On 02/17/2012 01:13 PM, Alan Cooper wrote:
> I'm seeing a problem on both 2.6.37 and 3.3 MIPS kernels where I can't
> unwind through a MIPS signal frame.
You don't tell us the version of the unwinder (likely from libgcc) you
are using. There was a lot of work in this area four or five years ago,
I didn't take the time to do the required archaeology to determine the
exact patch, but likely you are missing this.
> It looks like this is caused by
> the VDSO code that was added 2/2010.
Some CPUs have errata necessitating a different signal frame layout, on
these CPUs, you wouldn't be able to unwind either, even pre mips-vdso.
> When the unwinder tries to find
> the frame info for the caller of the signal handler (the trampoline in
> VDSO), it can't find the eh_frame info because the address is in the
> VDSO area and stops unwinding. It looks like other platforms solve
> this by adding the eh_frame info for the VDSO area so the lookup
> works.
That's right. However all 'modern' GCCs and GDBs can unwind through
signal frames on all 2.4.x and later kernels. I would recommend
upgrading your GCC to 4.6.2, and see if you obtain better results.
> This problem ends up breaking pthread cleanup for C++ programs because
> the cleanup is done using a class with the expectation that the
> destructor will be called when the thread gets canceled by a cancel
> signal. This seems like a big problem for all current MIPS kernels so
> I was wondering if I'm missing something?
A modern libgcc I think.
>
> If this is correct, then it seems like the best solution would be to
> add the VDSO eh_frame info to MIPS.
Having a correct eh_frame in the vdso, would be nice, but is not the
highest priority for me.
David Daney