This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]