This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Saving errno around signal handlers
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Richard Henderson <rth at twiddle dot net>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 03 Mar 2014 10:34:03 -0500
- Subject: Re: Saving errno around signal handlers
- Authentication-results: sourceware.org; auth=none
- References: <531077D9 dot 2000308 at redhat dot com> <5310BE05 dot 7090606 at twiddle dot net> <5310C04E dot 9090009 at redhat dot com> <5310C21E dot 1080501 at twiddle dot net> <Pine dot LNX dot 4 dot 64 dot 1402282213380 dot 17634 at digraph dot polyomino dot org dot uk> <53144417 dot 2010105 at redhat dot com>
On 03/03/2014 03:57 AM, Florian Weimer wrote:
> On 02/28/2014 11:16 PM, Joseph S. Myers wrote:
>> On Fri, 28 Feb 2014, Richard Henderson wrote:
>>
>>> I'll note that this *may* affect other tools, that have previously looked
>>> through trampolines via code inspection.
>>
>> I don't know if the comment in sysdeps/unix/sysv/linux/mips/sigaction.c is
>> still accurate:
>>
>> /* NOTE: Please think twice before making any changes to the bits of
>> code below. GDB needs some intimate knowledge about it to
>> recognize them as signal trampolines, and make backtraces through
>> signal handlers work right. Important are both the names
>> (__restore_rt) and the exact instruction sequence.
>> If you ever feel the need to make any changes, please notify the
>> appropriate GDB maintainer. */
>>
>> (<https://sourceware.org/glibc/wiki/Development_Todo/Master#MIPS> points
>> to a summary of known MIPS cases of CFI information missing in assembly
>> sources, which includes this one.)
>
> If we're fine with showing another stack frame in the backtrace of
> signal handlers, we could just avoid the fancy tail call and not
> change the restorer function at all. Then, from GDB's point of view,
> the signal handler is the glibc-provided wrapper (which obviously
> needs proper unwinding information etc.), and the user-installed
> handler is just some function called from a signal handler.
I'm not all that happy about that since that will certainly break
other tools that are only expecting the signal handler frame.
Cheers,
Carlos.