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