PR8554: New command to save breakpoints to a file
Michael Snyder
msnyder@vmware.com
Thu Apr 15 22:52:00 GMT 2010
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.
More information about the Gdb-patches
mailing list