Re: PR8554: New command to save breakpoints to a file

[Michael Snyder <msnyder@vmware.com>]

Michael Snyder wrote:
> 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.
> 
> 

... or perhaps "save" should be aliased to "save-tracepoints",
to mimic the previous behavior.