This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] add 'save-breakpoints' command
- From: Klee Dienes <klee at apple dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Klee Dienes <klee at apple dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 04 Dec 2001 13:43:53 -0500
- Subject: Re: [RFC] add 'save-breakpoints' command
- References: <E16BKC5-0002Wf-00@localhost> <20011204132721.A11047@nevyn.them.org>
- Reply-to: Klee Dienes <klee at apple dot com>
The way we addressed this in our sources was to add a new
'future-break' command, and modify the way we handle breakpoints that
cannot be inserted.
When our GDB is unable to set a breakpoint that has previously been
set successfuly, it marks the breakpoint as 'shlib_disabled'. Then
when shared libraries are loaded, GDB goes through the list of
shlib_disabled breakpoints and tries to re-set them.
The 'future-break' command allows one to specify a breakpoint that
starts off as 'shlib_disabled' instead of generating an error if it
can't be set immediately.
I'm not entirely happy with the future-break command, and particularly
with its interaction with the save-breakpoints mechanism (if you set a
breakpoint that is in a shared library after shared libraries have
been loaded, you have to remember to use the future-break command, not
the break command). This isn't a particularly big problem for us,
since we do decent good job of pre-loading symbols for all our shared
libraries --- but it's enough that I thought it better to treat as a
separate issue from the save-breakpoints command.