This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Breakpoint locations, enableness and MI's =breakpoint-modified event
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Jan Vrany <jan dot vrany at fit dot cvut dot cz>
- Cc: gdb at sourceware dot org
- Date: Sun, 27 May 2018 17:19:34 -0400
- Subject: Re: Breakpoint locations, enableness and MI's =breakpoint-modified event
- References: <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