#1 0x1234456765432189 in <signal handler>

#1 0x1234456765432189 in <signal handler>

[Andrew Cagney]

Hello,

At present a signal handler, in a backtrace is displayed as:

#0  catcher (signal=26) at 
/home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/sigaltstack.c:71
#1  <signal handler called>
#2  0x0000000000400751 in thrower (next_level=INNER, sig=26, itimer=1, 
on_stack=134217728) at /home/cygnus/cagney/GD

It isn't exactly informative.  Since we're now expecting GDB to do 
something sane with a signal handlers, I think how it is displayed 
should be changed.  In particular the output should be changed to:

#1  0xffff01111111 in <signal handler>

thoughts?

Andrew

Re: #1 0x1234456765432189 in <signal handler>

[Kevin Buettner]

On Fri, 23 Apr 2004 11:00:03 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> At present a signal handler, in a backtrace is displayed as:
> 
> #0  catcher (signal=26) at 
> /home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/sigaltstack.c:71
> #1  <signal handler called>
> #2  0x0000000000400751 in thrower (next_level=INNER, sig=26, itimer=1, 
> on_stack=134217728) at /home/cygnus/cagney/GD
> 
> It isn't exactly informative.  Since we're now expecting GDB to do 
> something sane with a signal handlers, I think how it is displayed 
> should be changed.  In particular the output should be changed to:
> 
> #1  0xffff01111111 in <signal handler>
> 
> thoughts?

I have no objection to printing an address, but I don't think
that referring to the thing in frame #1 as "<signal handler>"
is correct.  The signal handler in this case is actually catcher().
Frame #1 is created by the OS to hold the process's state prior to
receiving the signal in question.  That being the case, I'd like to
see either:

#1  0xffff01111111 in <signal handler caller>

or:

#1  0xffff01111111 in <signal context frame>

Kevin

Re: #1 0x1234456765432189 in <signal handler>

[David Daney]

Kevin Buettner wrote:

>On Fri, 23 Apr 2004 11:00:03 -0400
>Andrew Cagney <cagney@gnu.org> wrote:
>
>  
>
>>At present a signal handler, in a backtrace is displayed as:
>>
>>#0  catcher (signal=26) at 
>>/home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/sigaltstack.c:71
>>#1  <signal handler called>
>>#2  0x0000000000400751 in thrower (next_level=INNER, sig=26, itimer=1, 
>>on_stack=134217728) at /home/cygnus/cagney/GD
>>
>>It isn't exactly informative.  Since we're now expecting GDB to do 
>>something sane with a signal handlers, I think how it is displayed 
>>should be changed.  In particular the output should be changed to:
>>
>>#1  0xffff01111111 in <signal handler>
>>
>>thoughts?
>>    
>>
>
>I have no objection to printing an address, but I don't think
>that referring to the thing in frame #1 as "<signal handler>"
>is correct.  The signal handler in this case is actually catcher().
>Frame #1 is created by the OS to hold the process's state prior to
>receiving the signal in question.  That being the case, I'd like to
>see either:
>
>#1  0xffff01111111 in <signal handler caller>
>
>or:
>
>#1  0xffff01111111 in <signal context frame>
>  
>
There are typically several other things that are known about the signal 
at this point.  How about adding signal number (or name), cause, 
faulting address, etc.

David Daney

Re: #1 0x1234456765432189 in <signal handler>

[Andrew Cagney]

> Kevin Buettner wrote:
> 
>> On Fri, 23 Apr 2004 11:00:03 -0400
>> Andrew Cagney <cagney@gnu.org> wrote:
>>
>>  
>>
>>> At present a signal handler, in a backtrace is displayed as:
>>>
>>> #0  catcher (signal=26) at /home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/sigaltstack.c:71
>>> #1  <signal handler called>
>>> #2  0x0000000000400751 in thrower (next_level=INNER, sig=26, itimer=1, on_stack=134217728) at /home/cygnus/cagney/GD
>>>
>>> It isn't exactly informative.  Since we're now expecting GDB to do something sane with a signal handlers, I think how it is displayed should be changed.  In particular the output should be changed to:
>>>
>>> #1  0xffff01111111 in <signal handler>
>>>
>>> thoughts?
>>>   
>>
>>
>> I have no objection to printing an address, but I don't think
>> that referring to the thing in frame #1 as "<signal handler>"
>> is correct.  The signal handler in this case is actually catcher().
>> Frame #1 is created by the OS to hold the process's state prior to
>> receiving the signal in question.

Right, however

 >> That being the case, I'd like to
>> see either:
>>
>> #1  0xffff01111111 in <signal handler caller>
>>
>> or:
>>
>> #1  0xffff01111111 in <signal context frame>

on this mailing list, we refer to it as:

	#1 0x1234 in <signal trampoline>

so we might as well be consistent and use that.

>>
> There are typically several other things that are known about the signal at this point.  How about adding signal number (or name), cause, faulting address, etc.

A thing to look at one day is per-frame "info frame" information.

Andrew