PR8554: New command to save breakpoints to a file

Michael Snyder msnyder@vmware.com
Thu Apr 15 22:49:00 GMT 2010


Pedro Alves wrote:
> On Thursday 15 April 2010 19:58:44, Michael Snyder wrote:
>>>>> OTOH, it may be useful to be able to dump watchpoints on locals,
>>>>> and be able to load them up when you know it's okay, so never
>>>>> dumping those isn't that great either.  So, IMO, we shouldn't
>>>>> worry much about those, at least, in this first patch.  :-)  I
>>>>> could add a note to the manual, perhaps.
>>>> That's cool.  So what do we do now?  Just skip them?
>>>> Save the global ones, skip the local ones?
>>> We save them.
>>>
>> Oh -- and on reload, some of them fail?
>>
>> Shouldn't be difficult to skip saving all of them, but what about
>> skipping the locals and saving the globals?  Hard?
> 
> As I said above, it may be useful to be able to dump watchpoints
> on locals, and be able to load them up when you know it's okay,
> so never dumping those isn't that great either.  It's not hard,
> it's just not always the right thing.  As is, the user can edit the
> script if the wants to zap some breakpoints before sourcing it.  It's
> just a CLI script.  If you want to add a new command switch to
> tune the behaviour, that'd be cool.
> 

Fair enough.

BTW. "save_command" needs to print an error or something, not
simply return without doing anything.  If I type "save<return>",
I get a silent failure.




More information about the Gdb-patches mailing list