Re: New command to save breakpoints?

[Joel Brobecker <brobecker@adacore.com>]

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