This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI level command


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]