This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI level command
- From: Bob Rossi <bob at brasko dot net>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Alain Magloire <alain at qnx dot com>, gdb at sources dot redhat dot com
- Date: Tue, 24 Aug 2004 19:54:47 -0400
- Subject: Re: MI level command
- References: <200407082333.TAA25718@smtp.ott.qnx.com> <412BBB2D.7040108@gnu.org>
On Tue, Aug 24, 2004 at 06:03:25PM -0400, Andrew Cagney wrote:
> >Yellow
> >
> >
> >Scenario: We want to know wich level of MI that we are currently working
> >in.
> > This can allow to adjust what MI command to use and how to parse them.
> >
> >Problems: No such command in MI and no GDB variable that we can test via
> >-gdb-show.
> > The version of gdb
> > gdb --version
> > show different things in different distributions, sometimes it is a
> > number based on date
> > etc ...
> >
> >So would a patch implementing
> >
> > -gdb-mi-level
> > ^done,level=1
> >
> >be a good thing ?
>
> This needs to be resolved.
>
> I think its become clear that clients are choosing to support multiple
> debugger releases rather than certifying against a single debugger and
> mi version. This is contrary to the expectation that the clients would
> tightly couple their front end to a specific GDB and MI version, and
> consequently, when starting GDB, specify a specific MI version.
>
> Given this, we need to change the way versioning is handled.
>
> - we can't create a situtation where GDB is required to retain existing
> [broken] behavior indefinitly
>
> - we can certainly look for ways that let the client use both old and
> newer GDB's - the clients then get to decide how much backward
> incompatibility they wish to retain without imposing the burdon on GDB.
>
> To that end:
>
> -> we should probably implement significant command output (and more
> importantly input) changes by adding a new command. A missing new
> command is easy to detect, just run it with no options.
>
> -> minor output changes (new field for instance) do not need a new command
>
> -> MI version changes tied to significant changes
Agreed, this would be a *great* step in the right direction. I propose
that for every mi command, we give the signature, so that the client
knows exactly what the command is capable of. Just saying that a command
is there is not good enough.
It's very similar to POSIX coming out with a standard that says, the
function named select and poll must be present and then a C programmer
trying to interface with that function.
Thanks,
Bob Rossi