This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI level command
- From: "Alain Magloire" <alain at qnx dot com>
- To: cagney at gnu dot org (Andrew Cagney)
- Cc: alain at qnx dot com (Alain Magloire), gdb at sources dot redhat dot com
- Date: Wed, 25 Aug 2004 09:23:21 -0400 (EDT)
- Subject: Re: MI level command
>
> > 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.
>
Yes, some embedded platforms are still using old versions and for whatever
reasons and can not move the latest/greatest. Frontends still need to cope
with this and detecting the version of MI will allow them to adjust.
> 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
>
100% agreement, here 8-).
Thanks.