Re: New command to save breakpoints?

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Oct 11, 2005 at 10:42:55AM -0700, Joel Brobecker wrote:
> Hello,
> 
> some of our customers have asked us to enhance the debugger to be able
> to save breakpoints in a file, in order to reset them later. We feel
> it's a useful functionality to have and share with the rest of the
> GDB community.
> 
> Within AdaCore, we have adopted the interface that Apple has implemented
> in their own version of the debugger. So they added a command called
> "save-breakpoint" which will generate a set of GDB commands re-creating
> each breakpoint. To reset the breakpoints, one just "source"s this
> file.

I like thie idea, with caveats.

> I personally like the simplicity of this approach. There are a few
> issues we need to discuss, however:

More than just these...

>   . What happens if one of the breakpoints is inside a shared library
>     and that the symbols for the library haven't been loaded yet?
>     The current result depends on the "breakpoint pending" setting.

Pending breakpoints should be forced on while loading the saved
breakpoints file, surely?

>   . What happens if one of the breakpoints locations is OBE and
>     leads to an error? Again, depending on the "breakpoint pending"
>     setting, the script will either set a pending breakpoint, ignore
>     silently, or abort.

The closest matches I can find are "out of body experience" and "oracle
by example".  I'm going to assume that you want something sort of like
the former...

It should warn and ignore, presumably.

Reloading saved breakpoints is, fundamentally, the same problem as
resetting breakpoints after reloading an executable or shared library. 
We need the same information and it would be nice to commonize the two
a bit better.  Here's some other hangups I remember from when I looked
at the latter problem last:

  - there's at least one reference to the "current" language when
    setting breakpoints; if your application is C++ and the startup
    code has debug info tagging it as C or assembly, this can break
    down badly.

  - what if a breakpoint location is still valid, but the conditional
    check no longer parses there?

I think there's more, but I can't remember what they might have been.
So maybe not.

-- 
Daniel Jacobowitz
CodeSourcery, LLC