From: Simon Marchi <simon.marchi@polymtl.ca>
To: Jan Vrany <jan.vrany@fit.cvut.cz>
Cc: gdb@sourceware.org
Subject: Re: Breakpoint locations, enableness and MI's =breakpoint-modified event
Date: Sun, 27 May 2018 21:19:00 -0000 [thread overview]
Message-ID: <4fa6d696191ab3200cc9ef1a6bee7206@polymtl.ca> (raw)
In-Reply-To: <eb07558e0f4164eb7750c252ae153b7c0eb0747e.camel@fit.cvut.cz>
On 2018-05-23 06:14, Jan Vrany wrote:
> Hi there,
Hi Jan,
> when using MI, an MI event =breakpoint-modified is emitted if
> breakpoint
> enableness is changed via CLI command (such as 'dis 1'). However, if
> breakpoint location is changed (such as 'dis 1.1'), no event is emitted
> so the frontend may get out of sync.
That sounds like a bug.
> Is there any reason for this?
> Also, why the event is not emitted when breakpoint enablement is
> changed via MI command -break-enable?
Changes directly initiated by the MI frontend do not generate MI events
towards that frontend. When the frontend receives the successful
response to its command, it already knows that the change went through.
If there are multiple MI channels (created using the new-ui command),
the MI frontends other than the one that sent the command should receive
the event. That doesn't seem to work either, I would consider that a
bug.
> In case this is a bug, I tried to fix it and emit the event even for
> breakpoint location changes (see the patch below, testcase included).
> In short, I have extended gdb::observers::breakpoint_modified to take
> also the location (or nullptr) and notify() it also when location
> enableness changes, passing the specific location. The MI hook is
> updated accordingly, the rest is left as it was. Other uses of
> gdb::observers::breakpoint_modified may need to be updated too (python,
> guile & tui comes to mind).
>
> Best, Jan
Thanks, I'll reply with comments about the patch in another message
where I CC gdb-patches@ instead of gdb@.
Simon
prev parent reply other threads:[~2018-05-27 21:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 10:14 Jan Vrany
2018-05-27 21:19 ` Simon Marchi [this message]
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=4fa6d696191ab3200cc9ef1a6bee7206@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb@sourceware.org \
--cc=jan.vrany@fit.cvut.cz \
/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