From: Daniel Jacobowitz <drow@false.org>
To: Michael FIG <michael-dated-1177034790.7f6941@fig.org>
Cc: gdb@sourceware.org
Subject: Re: debugging a program that uses SIGTRAP
Date: Wed, 21 Mar 2007 02:18:00 -0000 [thread overview]
Message-ID: <20070321021809.GA2523@caradoc.them.org> (raw)
In-Reply-To: <7qy7lruz89.fsf@babe.fig.org>
On Tue, Mar 20, 2007 at 08:06:30PM -0600, Michael FIG wrote:
> Hi, all...
>
> How do you folks debug GDB under GDB?
It's quite easy. GDB never generates SIGTRAPs in itself, only in the
program it is debugging. The outer GDB is only looking at the inner
GDB, not at the program the inner GDB is controlling.
> However, when I change the handling of SIGTRAP to do this
> automatically, my program dies:
>
> (gdb) handle SIGTRAP pass
> SIGTRAP is used by the debugger.
> Are you sure you want to change it? (y or n) y
> Signal Stop Print Pass to program Description
> SIGTRAP Yes Yes Yes Trace/breakpoint trap
> (gdb) r
> Starting program: /fig/home/michael/sw/libstackless/t
>
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.
> (gdb)
>
> The program is attached below.
When you do this, it's not just resending SIGTRAPs that it would
display, but also all the internal ones. In this particular case it's
probably something from the shared library initialization breakpoint,
before main and before you have a SIGTRAP handler. Even if you get
past that point, your handler will now get called every time GDB hits
a breakpoint or single steps - single stepping will probably be
broken.
I don't see any good way to solve this. You've got two sets of
breakpoints and they're both going to stop GDB - it doesn't know which
ones you want and which you don't.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2007-03-21 2:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-21 2:06 Michael FIG
2007-03-21 2:18 ` Daniel Jacobowitz [this message]
2007-03-21 2:34 ` Michael FIG
2007-03-21 11:14 ` Daniel Jacobowitz
2007-03-23 4:30 ` Michael FIG
2007-03-21 14:14 ` Joel Brobecker
2007-03-21 18:51 ` Michael Snyder
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=20070321021809.GA2523@caradoc.them.org \
--to=drow@false.org \
--cc=gdb@sourceware.org \
--cc=michael-dated-1177034790.7f6941@fig.org \
/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