* #1 0x1234456765432189 in <signal handler>
@ 2004-04-26 7:59 Andrew Cagney
2004-04-26 19:46 ` Kevin Buettner
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2004-04-26 7:59 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: #1 0x1234456765432189 in <signal handler>
2004-04-26 7:59 #1 0x1234456765432189 in <signal handler> Andrew Cagney
@ 2004-04-26 19:46 ` Kevin Buettner
2004-04-26 20:48 ` David Daney
0 siblings, 1 reply; 4+ messages in thread
From: Kevin Buettner @ 2004-04-26 19:46 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: #1 0x1234456765432189 in <signal handler>
2004-04-26 19:46 ` Kevin Buettner
@ 2004-04-26 20:48 ` David Daney
2004-04-28 16:12 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: David Daney @ 2004-04-26 20:48 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: #1 0x1234456765432189 in <signal handler>
2004-04-26 20:48 ` David Daney
@ 2004-04-28 16:12 ` Andrew Cagney
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2004-04-28 16:12 UTC (permalink / raw)
To: David Daney, Kevin Buettner; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-04-28 15:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-26 7:59 #1 0x1234456765432189 in <signal handler> Andrew Cagney
2004-04-26 19:46 ` Kevin Buettner
2004-04-26 20:48 ` David Daney
2004-04-28 16:12 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).