This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop interface details
On Thursday 01 May 2008 21:52:00 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
> >
> >
> >>> In DSF-GDB there _is_ a central place where commands are sent, this is
> >>> where the protocol state is adjusted using -thread-select. However, the
> >>> --thread option is being added to many but not all commands, so the same
> >>> mechanism that adds the -thread-select could not be reused to add
> >>> --thread option. Instead each command which accepts --thread that would
> >>> need to be adjusted to use the --thread, but only when in non-stop
> >>> debugging mode.
> >>>
> >>
> >>
> >> This is not actually. The plan is for eery command will accept --thread.
> >> Those that don't have any use of it will ignore it. The only command,
> >> at the moment, for which the meaning of --thread is not yet clear, and for
> >> which the frontend might have to have custom decision logic, is --exec-continue.
> >>
> >> - Volodya
> >>
> >> That's helpful. Unfortunately UI clients that want to have a wide user base still
> >> need to worry about old GDB versions which do not support -thread, and that was my
> >> first point in this thread. As I've seen on this mailing list there are users out
> >> there still on GDB 5.x. I expect it will take several
> >> years before support for GDB 6.8 and prior is not so important.
> >>
> >
> > And where's the issue? On startup, issue -list-features. If you get error, this is old
> > GDB. If the output of -list-features does not include "thread-option", this version of
> > GDB does not support --thread (and don't not support non-stop, either). Then, you
> > can make appropriate runtime decisions. It seems better to me to make such global
> > decision right after starting GDB, rather than guessing things from output of *stopped,
> > and other indirect mechanisms.
> >
> >
> > [Note that "thread-option" is not yet produced by -list-features, because the support
> > for --thread is not yet in FSF tree]
> >
> > - Volodya
> >
> I disagree. I think it is more direct to place the logic of deciphering
> the meaning of the event with the code that handles that event. If
> there are optional fields in the event, they can be interpreted if
> present and interpreted another way if not present, but the logic is
> very localized.
> Using -list-features to determine what the protocol behavior is, forces
> the client to scatter logic about how to interpret events and use
> commands. The code that launches and configures GDB is typically in a
> different component than the code that interprets events and sends
> individual commands. In other words, the problem with using
> -list-features to determine the protocol behavior is that it makes it
> more difficult for the client to keep its code modular.
I guess I have different opinion on modularity -- it's quite possible
for the startup code to inform each inidividual module how it should
behave. Given that traditionally, MI often omits a field if it has
some "default" value, I'm sure you'll run into cases where you don't know
where absence of a field means that GDB is too old, or GDB has a bug,
or the field has a default values, etc.
> (warning: soap box speach coming)
> I have to admit though that history is on your side. Through its many
> versions GDB has freely changed (or "cleaned up") the MI protocol in
> subtle ways without warning (e.g. adding quotes around the condition
> parameter in -break-condition). This creates headaches for clients, and
> can ultimately make the client code difficult to maintain. A perfect
> example of this is the CDI-GDB Eclipse integration. While it has other
> architectural issues, the myriad of workarounds for various GDB versions
> in it makes it difficult to know whether a change for latest GDB version
> won't break support for old GDB versions. What I don't think GDB
> maintainers realize is that ultimately this policy does a lot of harm to
> GDB adoption and GDB's reputation in the larger community. I would
> guess that most users of GDB have some kind of graphical interface and
> their quality is linked to perception of quality of GDB. GDB/MI is a
> published protocol with many users, and I wish that this fact had more
> significance to its maintainers.
GDB/MI is actually not a finished published protocol -- it's work in progress.
Unfortunately, frontend maintainers tended to read between the lines, and guess
the behaviour and accepted input instead of asking here. And in cases where what
they've read between the lines does not correspond to what GDB developers means,
the result is a buggy frontend :-)
Given that MI, presently, is still not adequate for such basic tasks as
listing local variables in a function, it will change, and it might break
things, and frontend developers should provide the input to avoid surprises.
You and Marc represent Eclipse here, and Nick represent Emacs, and
I represent KDevelop, so those three are fine, but other frontend developers
should be more active here.
Probably, I should add big warning to MI manual, saying that everything that is not
100% clear must be asked on the list.
- Volodya