From: Tom Tromey <tromey@redhat.com>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Breakpoint MI notifications
Date: Tue, 26 Apr 2011 16:04:00 -0000 [thread overview]
Message-ID: <m38vuxrodc.fsf@fleche.redhat.com> (raw)
In-Reply-To: <201104261508.20380.vladimir@codesourcery.com> (Vladimir Prus's message of "Tue, 26 Apr 2011 15:08:20 +0400")
>>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
Volodya> The enclosed patch implements MI notifications about breakpoint
Volodya> changes. As other MI notifications, those are emitted only
Volodya> when breakpoint changes by something that is not a MI command
Volodya> to change a breakpoint. For example, -break-condition will not
Volodya> cause a breakpoint-changed notification to be emitted.
Volodya> This functionality was independently written by Tom and myself,
Volodya> and this patch merges the patches together. As a side effect,
Volodya> existing breakpoint observers were modified to take a pointer
Volodya> to breakpoint rather than it, which eliminates quite some
Volodya> busywork.
Thanks for doing this.
A few nits on the code part, nothing serious though.
Volodya> @@ -5061,7 +5060,12 @@ print_one_breakpoint (struct breakpoint *b,
Volodya> struct bp_location **last_loc,
Volodya> int allflag)
Volodya> {
[...]
Volodya> + struct cleanup *inner = make_cleanup (null_cleanup, 0);
I don't think you need this cleanup.
Volodya> +static int
Volodya> +locations_are_equal (struct bp_location *a, struct bp_location *b)
A new function should have an introductory comment.
Volodya> -static void
Volodya> +void
Volodya> disable_command (char *args, int from_tty)
I didn't see any use of this function elsewhere, so I think the 'static'
can stay.
Volodya> -static void
Volodya> +void
Volodya> enable_command (char *args, int from_tty)
Likewise.
Volodya> +@deftypefun void breakpoint_deleted (struct breakpoint *@var{b})
Volodya> A breakpoint has been destroyed. The argument @var{bpnum} is the
Volodya> number of the newly-destroyed breakpoint.
Volodya> @end deftypefun
The body of the documentation should be updated too.
Volodya> -@deftypefun void breakpoint_modified (int @var{bpnum})
Volodya> +@deftypefun void breakpoint_modified (struct breakpoint *@var{b})
Volodya> A breakpoint has been modified in some way. The argument @var{bpnum}
Volodya> is the number of the modified breakpoint.
Likewise.
Volodya> +int mi_suppress_breakpoint_notifications = 0;
Volodya> +
Volodya> +static void
Volodya> +mi_breakpoint_created (struct breakpoint *b)
Volodya> +{
Comments on new functions and globals.
Volodya> + if (strstr (parse->command, "break-") == parse->command)
I think strncmp would be more idiomatic here.
This implementation seems fragile, but that is your call.
Volodya> /* Callback that is used when a breakpoint is created. This function
Volodya> will create a new Python breakpoint object. */
Volodya> static void
Volodya> -gdbpy_breakpoint_created (int num)
Volodya> +gdbpy_breakpoint_created (struct breakpoint *bp)
Volodya> {
Volodya> breakpoint_object *newbp;
Volodya> - struct breakpoint *bp = NULL;
Volodya> PyGILState_STATE state;
Volodya> - bp = get_breakpoint (num);
Volodya> - if (! bp)
Volodya> - return;
Volodya> -
Volodya> - if (num < 0 && bppy_pending_object == NULL)
Volodya> - return;
I am not sure that removing this test is ok.
Tom
next prev parent reply other threads:[~2011-04-26 16:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 11:09 Vladimir Prus
2011-04-26 16:04 ` Tom Tromey [this message]
2011-04-26 18:36 ` Vladimir Prus
2011-04-26 20:15 ` Tom Tromey
2011-04-27 21:12 ` [patch] testsuite: unknown output after running [Re: Breakpoint MI notifications] Jan Kratochvil
2011-04-28 5:58 ` Vladimir Prus
2011-04-28 7:32 ` Jan Kratochvil
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=m38vuxrodc.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@codesourcery.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