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 01:47:57PM -0400, Paul Koning wrote:
> >>>>> "Bob" == Bob Rossi <Bob> writes:
> 
>  >> > 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.
> 
>  Bob> I guess the bottom line is, I already have a parser that is
>  Bob> capable of dealing with a specific version of MI's output. I
>  Bob> don't want to start up MI with an adhoc parser, just to figure
>  Bob> out what real parser I should use. This seems not correct to me,
>  Bob> and I guess it's the issue to deal with.
> 
> Bob, that actually IS correct and the conventional way to handle
> things.  In typical protocol design, the conversation starts with a
> message that carries version information.  The protocol state machine
> initially comes up in a state where it expects that message and knows
> how to find the version information.  Once it knows that, it flips to
> the state machine for that version.
> 
> Note that the "ad hoc" part typically only involves one or two
> messages and often only a small part of the content of those
> messages.  For example, the initial message might be a "create
> connection" message, carrying dozens of fields one of which is a
> version number.  The first step is to find that version number; after
> that is known, all the rest including the full parse of that initial
> message can be done by the full parse machinery.

Yes, you are correct. I understand this. I think the problem is 2 fold.
It is confusing and (IMO) incorrect to add a command to the MI function
set that can not be used for the purposes that it needs to be by a program 
that speaks the MI protocol. I new parser needs to be written that does
not conform to the MI protocol.

MI is an evolving protocol, and it would be useful to just have either a
command line swith, which could send info in a trivial line based
manner, or have a new interpreter, that only says what other
interpreters that the current GDB supports.

These are simple solutions that would not involve much from the front
end developer and would result in code that could be written probably to
a format that will not change.

Thanks,
Bob Rosi


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