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
