This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PR8554: New command to save breakpoints to a file
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 09 Apr 2010 10:17:31 -0600
- Subject: Re: PR8554: New command to save breakpoints to a file
- References: <201004090341.14389.pedro@codesourcery.com>
- Reply-to: tromey at redhat dot com
>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
Pedro> (I finished this instead of dumping it.)
Thanks. I do like this approach.
Pedro> Add a new save-breakpoints command to save breakpoint definitions
Pedro> to a file.
I'd personally prefer "save breakpoints", with a space, and make
save-tracepoints a deprecated alias for "save tracepoints". What do you
(and others) think of this? I tend to like simple commands with spaces,
especially when a subcommand comes along.
Pedro> The new breakpoint_ops->print_recreate method implementation for
Pedro> all catchpoints is always mostly a simplified version of
Pedro> breakpoint_ops->print_mention method.
Could you enlighten me on a historical (?) point? Why is it that some
kinds of breakpoints have methods like this and some do not? Is this an
incomplete transition, or an intentional design choice?
Pedro> + if (tp->thread != -1)
Pedro> + fprintf_unfiltered (fp, " thread %d", tp->thread);
Pedro> +
Pedro> + if (tp->task != 0)
Pedro> + fprintf_unfiltered (fp, " task %d", tp->task);
Pedro> +
Pedro> if (tp->cond_string)
Pedro> fprintf_unfiltered (fp, " if %s", tp->cond_string);
I don't think this syntax will work for a conditional catchpoint.
Our Python-based implementation gets this wrong as well. I think you
need a separate "cond" command in the output.
Tom