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 06:14:49PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi' 
> > Sent: 06 October 2004 18:05
> 
> > Sorry if I was rude here, I am very frustrated.
> 
>   It shows.  But seriously, if you have to keep on saying the same thing
> over and over again, we're not disagreeing with you just to be contrary,
> it's because either _we_ haven't understood the problem, or because _you_
> haven't understood the solutions we've proposed.  At that point, there's a
> communication difficulty going on, which will not be resolved by simply
> repeating the same description over and over getting more angry each time.

Understood.

> > No one has attempted to do what I am trying to do. Write a front end
> > that is capable of working with different GDB's.
> > 
> > If they do do this, I would like to know how they negotiate the MI
> > version to talk.
> > 
> > Again, you seem to be saying that if I generate a parser off of the MI
> > output syntax, that I am somehow wrong.
> 
>   No, that's not what I'm saying.  I fully accept that you have to know what
> version to deal with in order to invoke the correct full parser, and I fully
> accept that while in general newer versions are supersets there are also
> genuine backwards-incompatibilities that would require different parsing.
> It's entirely proper to generate a parser from the MI output syntax.
> 
>   The only thing I'm disagreeing is your assumption that there's no way of
> determining which MI version to talk without using a full MI parser.  You
> can do it MUCH more simply than that.  That's the point which people keep on
> having to repeat to you each time you repeat your description of the
> problem, because while everyone understands the initial problem, nobody sees
> what's wrong with the solutions that have been proposed so far.

You are the first person so far that has pointed out directly to me that
you understand the problem I am describing.

> > Is this the general feel of the community?
> 
>   Well, it's not what I feel, as I hope I've explained patiently above.  I
> wouldn't care to speak for the community at large, but I would be surprised
> if anyone else felt that it was wrong to generate a parser from the MI
> output syntax.  What I feel is wrong is your assumption that a generated
> parser is the only possible means of processing plain ascii human readable
> text for the purpose of finding and extracting a single integer value.

I guess the bottom line is, I already have a parser that is capable of
dealing with a specific version of MI's output. I don't want to start up
MI with an adhoc parser, just to figure out what real parser I should
use. This seems not correct to me, and I guess it's the issue to deal
with. 

The problem is, we would be adding a command to the MI function set that
would not be able to be parsed and understood with an MI parser. This
seems really wrong to me. It's probably the issue we should be
discussing.

Thanks,
Bob Rossi


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