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

[Michael Snyder <msnyder at vmware dot 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.