This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI3 and async notifications
- From: Jan Vrany <jan dot vrany at fit dot cvut dot cz>
- To: Simon Marchi <simark at simark dot ca>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Tom Tromey <tom at tromey dot com>, André Pönitz <apoenitz at t-online dot de>, Jonah Graham <jonah at kichwacoders dot com>
- Date: Tue, 18 Jun 2019 21:38:19 +0100
- Subject: Re: MI3 and async notifications
- References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca>
Hi,
> I am skeptical about the complex logic you are talking about to handle both
> =breakpoint-created notifications and responses to the -break-insert. Both contain pretty
> much the same information. So rather than adding an option in GDB for emitting async
> notifications unconditionally, can't you just process both using the same function? That
> doesn't really complicated, but maybe I am misunderstanding your problemi, in which case
> please expand.
OK, let me expand (hopefully not too much)
I have a (general purpose) library that provides higher-level interface
to GDB/MI. Strictly speaking, it is not bound to any particular UI frontend.
This library essentially provides three things:
(i) (supposedly) easy to use API to send MI commands, like:
gdb send: (GDBMI_break_insert arguments: { 'main' }) andWithResultDo:[ :result |
result isSuccess ifTrue:[
Stdout print: 'Breakpoint inserted'
] ifFalse:[
Stderr print: 'Oops, something went wrong!'
]
]
(sorry for bit arcane syntax, hope you can make sense of it)
(ii) provide object model of the debugger and its state (like, inferiors, their threads,
frames in thread, variables, registers, breakpoints) like:
"/ Prints the stack of first thread"
gdb selectedInferior threads first stack do:[:frame|
Stdout print: frame printString
]
The idea is that if the inferior is stopped, the model is up-to-date, when it's running,
then "reasonable up-to-date", no guarantees.
(iii) provide a way to get notified of changes, like:
gdb when: GDBBreakpointModifiedEvent do: [:event |
"/ something has changed, redraw the list to display
"/ up-to-date information
breakpointListPane redraw.
]
This is essential to build an UI on top of this library
All the above is API exposed to library user. This design has the advantages
of being flexible - users can issue commands on their own, I do not have to
implement and maintain wrapping API rich enough to handle all cases - and
and because is close to GDB/MI, I don't really need to document it in depth, looking to
GDB documentation gives you very good idea what how to use it. Reusing GDB events
to notify clients of my library has the same advantage - no need to implement my
own event hierarchy and document them.
But if I don't get events in cases when they're result of an MI command, the only
way I can think of handling it is to intercept command result event and:
1) examine the result (and sometimes the originating command itself) and do the
processing
2) synthesize an event as if it were send by gdb and push it back so it's delivered
to users of the library - but in this case I have to make sure it is delivered only
to "external" observers and not "internal" observers which are responsible of keeping
the model up-to-date.
Both steps have to cared for case-by-case (like, -break-insert response carries data
- the breakpoint inserted - while response to -gdb-set is plain ^done so in order to
update model I have to dig into the command itself, retrieve it's parameters and
reconstruct data from there).
All this is indeed doable and in fact, I do this already for some commands to meet my
need back then, but then I realized I need more of this and was thinking how to avoid
all that code. A quick experiment shows that always emitting a notification solves
most (all?) issues I experienced, which is why brought it here.
Does it make sense?
>
> It would be useful to have a very concrete use case where you could point out "see here,
> I am missing some info and a notification would be useful". It could very well be that
> some notifications are just missing.
To make me clear, I'm not saying that some information is missing, just that the way
it is delivered seem to be inconvenient given the way I use it. It may well be I use it
the wrong way :-)
> For example I would argue we are missing notifications
> if using two MI clients (through the new-ui command, although I don't remember if that's
> "officially" supported). If one of the MI client inserts a breakpoint with -break-insert,
> the other one is not notified. I would consider that a bug that the second client doesn't
> get a =breakpoint-created.
Yeah, having a second MI channel is a different story, I'm not considering this for now.
>
> Also, I am a bit worried by a proposal in the thread, which would be to remove information
> from the -break-insert ^done response, arguing that the async notification would have already
> been emitted. It is clear and unambiguous how to map a response to a request, but it would not
> be obvious to map an async notification to a request. So it appears to me as a regression in
> functionality.
This is why I said that - for example - for -break-insert we need to respond with - at least -
^done,bkpt-number=1. For some other. like -gdb-set I don't think we need to.
Thanks! Jan