[Top] [All Lists]

Stack unwind across signal frame

Subject: Stack unwind across signal frame
From: Alan Cooper <>
Date: Fri, 17 Feb 2012 16:13:54 -0500
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=mime-version:date:message-id:subject:from:to:content-type; bh=LppqU253m/LCE42418D3LZxx/9PAq2ucoAFMMsp94FY=; b=YgycvGy01Gwe5cjj2q0V8L2ZiYMO4r4VDGzZL6I0enewXyFwKnb5pfZtqPshsPTmWP MVVQjkysofpy7CN5YpOtkhs5FVYLewY1cg9QSYAq/uMHgaNJMn2SQraxI6feuQJQ9gA2 RaFYMZJQlf3lIG+MIWdrBhAuUIyPEIeiVhiyg=
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

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.

Al Cooper

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