New command to save breakpoints?

New command to save breakpoints?

[Joel Brobecker]

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 personally like the simplicity of this approach. There are a few
issues we need to discuss, however:

  . 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.

  . 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.

What do others think of this approach? If we can agree on it, I will
work on the implementation, probably drawing most of the code from
the last Apple source drop.

Thanks,
-- 
Joel

Re: New command to save breakpoints?

[Daniel Jacobowitz]

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

Re: New command to save breakpoints?

[Joel Brobecker]

> >   . 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?

I agree. This means we need to temporarily force "... pending" to off
and restore it later. I don't know of any way of doing this using
GDB's scripting language, so we're leaning towards the counter-part
of the save-breakpoints command, a new command that also restores
them?

So the design at the user-interface level would become something like this
(the command names can also be debated of course):

        . new command: ``save-breakpoints''
          stores breakpoints in script format (design unchanged)

        . new command: ``restore-breakpoints''
          saves the current breakpoint-pending status
          sources the script
          restores the breakpoint-pending status

> >   . 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.

That's my feeling too.

At the implementation level, however, this causes an extra difficulty
as simple sourcing of the script will abort if such error happens. So
we'll need to find a solution (such as diverting all errors during the
sourcing and transform them into warnings, or implement a switch to
the break command to report what normally are errors as warnings). Or
we can decide no use to a normal source, but something else. To be
determined.

> 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.

That's a very good point.

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

Not sure what is best to do in this case. It could be argued both ways,
really. Perhaps the most sensible thing to do is to insert the
breakpoint without the condition, and print a warning to the user.

If we agree that reloading saved breakpoints and resetting brekpoints
should use the same behavior/code, then we can discuss the problems
of the current GDB separately (I prefer breaking down problems in
smaller ones).

-- 
Joel

Re: New command to save breakpoints?

[Jim Ingham]

Sean Callanan submitted a patch a couple of months ago that would add  
a switch to continue execution after errors in "source" or "define"  
command executions.  He seems not to have cleaned it up after some  
comments from DanielJ, but that would probably do the trick for you  
here.

Jim

On Oct 14, 2005, at 12:38 PM, Joel Brobecker wrote:

> At the implementation level, however, this causes an extra difficulty
> as simple sourcing of the script will abort if such error happens. So
> we'll need to find a solution (such as diverting all errors during the
> sourcing and transform them into warnings, or implement a switch to
> the break command to report what normally are errors as warnings). Or
> we can decide no use to a normal source, but something else. To be
> determined.
>