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: probing GDB for MI versions


On Wed, Oct 06, 2004 at 02:41:09PM -0400, Andrew Cagney wrote:
> 
> >>>Will someone explain to me how they expect to write a parser 
> >>>capable of
> >>>getting some information out of MI2, but prove to me that it will work
> >>>with MI100.
> >
> >
> >  Simple.
> >
> >  Any time anyone proposes changing the output format of the -mi-version
> >command, or removing it, we'll just say no.  Fr'ex:
> >
> >  The -mi-version command will ALWAYS AND FOREVER output a string of the
> >format
> >
> >"Highest supported MI version is XXXX"
> 
> anything like that.
> 
> >where XXXX is an ASCII decimal integer.  Any program can then read the
> >output from an invocation of gdb and simply discard everything up until it
> >finds that string, then parse the integer out.
> 
> Right, and tested (as always) using the testsuite.
> 
> I find this focus on such pedantic details both puzzling and time 
> wasting.   Especially given that any code intended to handle multiple MI 
> variants must be adhoc.  Otherwize it won't work with all the variants 
> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.

You are stating that a parser that implements an MIn Output syntax has
to be adhoc? I plan on having a parser for each of these interface's and
none of them is adhoc. I don't think you should force your adhoc
approach onto the front end developers.

> MI needs is additional commands and extensions, driven by the needs of 
> Free software projects.  Neither of those - EMACS and Eclipse - appear 
> to be having problems this technical nits such as this.

I can't explain why. 

Bob Rossi


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