From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, pmuldoon@redhat.com
Cc: Tom Tromey <tromey@redhat.com>, dan@codesourcery.com
Subject: Re: [patch] Add visible flag to breakpoints.
Date: Sun, 31 Oct 2010 21:07:00 -0000 [thread overview]
Message-ID: <201010312107.38336.pedro@codesourcery.com> (raw)
In-Reply-To: <m3wrpa7xb9.fsf@redhat.com>
On Friday 22 October 2010 22:05:30, Phil Muldoon wrote:
> -/* Set a breakpoint. This function is shared between CLI and MI
> +/* Set a breakpoint. This function is shared between CLI and MI
Spurious, and incorrect whitespace change.
> functions for setting a breakpoint. This function has two major
> modes of operations, selected by the PARSE_CONDITION_AND_THREAD
> parameter. If non-zero, the function will parse arg, extracting
> breakpoint location, address and thread. Otherwise, ARG is just the
> location of breakpoint, with condition and thread specified by the
> - COND_STRING and THREAD parameters. Returns true if any breakpoint
> - was created; false otherwise. */
> -
> + COND_STRING and THREAD parameters. If INTERNAL is non-zero, the
> + breakpoint number will be allocated from the internal breakpoint
> + count. Returns true if any breakpoint was created; false
> + otherwise. */
> int
Two spaces after period, not three. Don't lose the empty line
between comment and function.
> create_breakpoint (struct gdbarch *gdbarch,
> @@ -7750,7 +7785,8 @@ break_command_1 (char *arg, int flag, int from_tty)
> pending_break_support,
> NULL /* breakpoint_ops */,
> from_tty,
> - 1 /* enabled */);
> + 1 /* enabled */,
> + 0 /* internal */);
> }
>
Inconsistent whitespace with the other cases. Please fix that
in all the several places this appears.
> int static_trace_marker_id_idx;
> - };
> +
> + /* With a Python scripting enabled GDB, store a reference to the
> + Python object that has been associated with this breakpoint.
> + This is always NULL for a GDB that is not script enabled. It
> + can sometimes be NULL for enabled GDBs as not all breakpoint
> + types are tracked by the Python scripting API. */
> + PyObject *py_bp_object;
> +};
Is the indentation correct here? Looks two spaces too much to the right.
> + if (internal)
> + /* Do not mention breakpoints with a negative number, but do
> + notify observers. */
> + observer_notify_breakpoint_created (b->number);
> + else
> + mention (b);
Same here. Please double check your patch for formatting -- there may be
other cases I missed.
> extern int create_breakpoint (struct gdbarch *gdbarch, char *arg,
> - char *cond_string, int thread,
> - int parse_condition_and_thread,
> - int tempflag, enum bptype wanted_type,
> - int ignore_count,
> - enum auto_boolean pending_break_support,
> - struct breakpoint_ops *ops,
> - int from_tty,
> - int enabled);
> + char *cond_string, int thread,
> + int parse_condition_and_thread,
> + int tempflag,
> + enum bptype type_wanted,
> + int ignore_count,
> + enum auto_boolean pending_break_support,
> + struct breakpoint_ops *ops,
> + int from_tty,
> + int enabled,
> + int internal);
Leftover reindent from "create_new_breakpoint"? Doesn't
look necessary or correct? Please undo.
> create_breakpoint (python_gdbarch,
> - spec, NULL, -1,
> - 0,
> - 0, bp_breakpoint,
> - 0,
> - AUTO_BOOLEAN_TRUE,
> - NULL, 0, 1);
> + spec, NULL, -1,
> + 0,
> + 0, bp_breakpoint,
> + 0,
> + AUTO_BOOLEAN_TRUE,
> + NULL, 0, 1, internal_bp);
Same here?
Otherwise looks fine to me. Thanks.
--
Pedro Alves
next prev parent reply other threads:[~2010-10-31 21:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 16:28 Phil Muldoon
2010-09-30 16:41 ` Daniel Jacobowitz
2010-09-30 17:51 ` Phil Muldoon
2010-09-30 17:55 ` Pedro Alves
2010-09-30 18:12 ` Phil Muldoon
2010-10-08 12:51 ` Phil Muldoon
2010-10-08 13:35 ` Pedro Alves
2010-10-08 14:04 ` Phil Muldoon
2010-10-08 18:44 ` Tom Tromey
2010-10-12 20:25 ` Phil Muldoon
2010-10-12 21:34 ` Tom Tromey
2010-10-13 12:45 ` Phil Muldoon
2010-10-13 13:06 ` Phil Muldoon
2010-10-13 15:36 ` Tom Tromey
2010-10-16 18:42 ` Pedro Alves
2010-10-16 19:03 ` Pedro Alves
2010-10-18 16:09 ` Tom Tromey
2010-10-22 21:05 ` Phil Muldoon
2010-10-22 21:31 ` Eli Zaretskii
2010-10-22 21:37 ` Phil Muldoon
2010-10-23 9:07 ` Eli Zaretskii
2010-10-31 21:07 ` Pedro Alves [this message]
2010-11-11 14:36 ` Phil Muldoon
2010-11-12 12:43 ` Ken Werner
2010-11-12 12:49 ` Pedro Alves
2010-11-12 12:58 ` Ken Werner
2010-10-08 18:40 ` Tom Tromey
2010-09-30 17:04 ` Pedro Alves
2010-09-30 17:55 ` Phil Muldoon
2010-09-30 17:51 ` Eli Zaretskii
2010-10-05 22:28 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201010312107.38336.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).