[Top] [All Lists]

Re: Stack unwind across signal frame

To: Alan Cooper <>
Subject: Re: Stack unwind across signal frame
From: David Daney <>
Date: Sat, 18 Feb 2012 09:05:52 -0800
Authentication-results:; spf=pass ( domain of designates as permitted sender); dkim=pass
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ofjvcW+huBFnj4YUG9kHeehWp+pd/TGS3sKdPTgy0Wk=; b=UAh1tx8YOKYypGYY/wdBezVVbG1fdYpvuVYjdlObAQPeBuNEb5yYl06Gc2IG2VGt3f ONBC0/xnTfCv5Thl+asNdV4xyH9awb91SSRnVFm1OsXwrZxZOP2GabS1aQ7CgXe92b75 DnF+VzclYkSDlUv1rDiZEYRiNBSKsM9GBQBAE=
In-reply-to: <>
References: <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
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

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

<Prev in Thread] Current Thread [Next in Thread>