From: Mark Kettenis <kettenis@chello.nl>
To: gdb@sources.redhat.com
Subject: Stepping through signal trampolines
Date: Thu, 25 Mar 2004 14:47:00 -0000 [thread overview]
Message-ID: <200403251333.i2PDXSq7006981@elgar.kettenis.dyndns.org> (raw)
The recent changes to the signal trampoline stuff have changed the way
we deal with stepping through signal trampolines. I did some
experimenting with an older GDB and noticed the following differences:
* Finish from within a signal handler now makes us end up in the
signal trampoline now, whereas an older GDB simply ran until exit.
I guess this is a good thing.
* Stepping out of the signal handler using "stepi" makes us run until
exit now, whereas an older GDB happily continues stepping into the
signal trampoline.
* If I use finish to get into the signal trampoline with a current
GDB, stepi continues until we return from the signal trampoline.
Using stepi on the older GDB from within the signal trampoline
happily steps through the signal trampoline.
So there still seem to be some quirks with stepping through signal
trampolines. But before we decide what's the bug, I think we should
ask ourselves what the desired behaviour is. In my view:
* "finish" from within a signal handler should make us return to the
signal trampoline.
* "finish" from within a signal trampoline should make us return to
the point where the signal interruption occured.
* "stepi" from within a signal handler should step through the signal
handler and back into the signal trampoline.
* "stepi" from within a signal trampoline should step through the
signal trampoline until the sigreturn system call.
I'm not sure what "next" and "step" should do exactly. Here we must
distinguish between systems with libc-provided signal trampolines and
systems with kernel-provided signal trampolines. For the latter we
usually won't have debug info, so "next" and "step" should probably
skip them. For the former, we probably want to make them stop at
lines within the signal trampoline if we have debug info for those
lines.
Thoughts?
Mark
next reply other threads:[~2004-03-25 13:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 14:47 Mark Kettenis [this message]
2004-03-25 19:59 ` Andrew Cagney
2004-04-05 22:48 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200403251333.i2PDXSq7006981@elgar.kettenis.dyndns.org \
--to=kettenis@chello.nl \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox