(a?)synchronous stepping commands in gdb MI, a week later

(a?)synchronous stepping commands in gdb MI, a week later

[Konstantin Karganov]

Sorry for the repeat...

Does anyone know why the "-exec-*" commands family in GDB MI is
declared asynchronous but in fact behaves synchronously (blocking the
interface until the execution completes)?

Thank you.

-- 
Best regards,
 Konstantin   

Re: (a?)synchronous stepping commands in gdb MI, a week later

[Andrew Cagney]

Konstantin Karganov wrote:
> Sorry for the repeat...
> 
> Does anyone know why the "-exec-*" commands family in GDB MI is
> declared asynchronous but in fact behaves synchronously (blocking the
> interface until the execution completes)?
> 
> Thank you.

Asynchronous behavior depends on an asynchronous backend.  At present 
only ``target async-remote'' is asynchronous (and then there's doubt 
that it still works), hence the behavior you're seeing.

Andrew

Re[2]: (a?)synchronous stepping commands in gdb MI, a week later

[Konstantin Karganov]

Hello Andrew,

>> Does anyone know why the "-exec-*" commands family in GDB MI is
>> declared asynchronous but in fact behaves synchronously (blocking the
>> interface until the execution completes)?

> Asynchronous behavior depends on an asynchronous backend.  At present 
> only ``target async-remote'' is asynchronous (and then there's doubt 
> that it still works), hence the behavior you're seeing.
So it's just obsolete documentation, that states asynchronous
behavior? Or there are plans to add asynchronous commands later?

One more question: when the execution of "next" (or "step") command in
GDB is interrupted is there a way to know where it would stop if not
interrupted?
Or, maybe, the way to continue the execution of interrupted GDB command
as if there was no interrupt?..

Thanks a lot.

-- 
Best regards,
 Konstantin 

complete GDB MI specification

[Konstantin Karganov]

Hello,

I'm going to implement a GUI debugger over GDB and need a complete
description of MI commands and their result formats. Where can I find
it?

The "Debugging with GDB" guide doesn't specify many details: for
example, the value of the expression is a string with unclear format
(i.e. "[0 <repeated 100 times>]" is a valid array value), the
"-var-update" response is not specified at all...

How can I make a parser for the grammar specified as "there should be
something like the result"? :)

Thanks in advance.

-- 
Best regards,
 Konstantin 

Re: complete GDB MI specification

[Eli Zaretskii]

> Date: Mon, 6 Dec 2004 19:21:30 +0300
> From: Konstantin Karganov <kostik@ispras.ru>
> 
> I'm going to implement a GUI debugger over GDB and need a complete
> description of MI commands and their result formats. Where can I find
> it?

In general, in the manual.

> The "Debugging with GDB" guide doesn't specify many details: for
> example, the value of the expression is a string with unclear format
> (i.e. "[0 <repeated 100 times>]" is a valid array value), the
> "-var-update" response is not specified at all...

Please report all such unclear cases, and I will try to fix them.

> How can I make a parser for the grammar specified as "there should be
> something like the result"? :)

There was a long series of discussions about a month ago, either here
or on gdb-patches.  Search for "MI" in the archives, and you will find
a patch with a formal parser grammar for the MI interface.

Re[2]: complete GDB MI specification

[Konstantin Karganov]

Hello Eli,

>> I'm going to implement a GUI debugger over GDB and need a complete
>> description of MI commands and their result formats. Where can I find
>> it?
> In general, in the manual.
"Note that the current ``grammar'' in the MI documentation, at least as
far as I'm concerned, is meant to be an informal introduction of the
MI syntax, not a rigurous grammar description." (ñ) Eli Zaretskii :)

And this is the problem! MI is supposed to be a program-to-program
interface and thus needs a complete formal description (at least, to be
sure that all possible output is handled correctly).

> There was a long series of discussions about a month ago, either here
> or on gdb-patches.  Search for "MI" in the archives, and you will find
> a patch with a formal parser grammar for the MI interface.
Looked through several (a lot, actually!) discussions and didn't found
what I need. There were several syntax patches and grammar
transformations (mostly by Bob Rossi and Michael Chastain), but all of
them concern general syntax of MI output but don't go into details and
the output semantics.

> Please report all such unclear cases, and I will try to fix them.
Look at the structure of MI description: there are the command syntax
with explanation and the example of the output. Just an example
instead of complete output specification. Yes, it fits the general case
of " var=value (,var=value)* " syntax but the actual semantics and
possible value pairs are not specified. That is for all commands.

Another practical example: displaying the value of the array variable.
It turns out, that the value of the array fits the "c-string" grammar
terminal symbol. But the inner structure of this string is not
specified. I expected that there should be a list of values of the
array length, but it turned out that there is at least one
optimization in the form of "X <repeated N times>". What other tricks
are possible in value string? :)

Anyway, it looks weird if no rigorous specification of MI output
exist. IMHO it means (if it is) that no one uses MI in real systems
(except the tests and demo purposes)...


-- 
Best regards,
 Konstantin 

Re: complete GDB MI specification

[Bob Rossi]

> > There was a long series of discussions about a month ago, either here
> > or on gdb-patches.  Search for "MI" in the archives, and you will find
> > a patch with a formal parser grammar for the MI interface.
> Looked through several (a lot, actually!) discussions and didn't found
> what I need. There were several syntax patches and grammar
> transformations (mostly by Bob Rossi and Michael Chastain), but all of
> them concern general syntax of MI output but don't go into details and
> the output semantics.

I have not had any time to work lately. However, when I get time again,
I plan on formalizing the grammar and hopefully running a parser off of
this grammar through the MI testsuite to verify GDB's output.

Also, I plan on updating the doco to match the actual grammar. I want to
do this because I plan on using this grammar to write a parser capable
of working with GDB for my own personal Free Software project.

> > Please report all such unclear cases, and I will try to fix them.
> Look at the structure of MI description: there are the command syntax
> with explanation and the example of the output. Just an example
> instead of complete output specification. Yes, it fits the general case
> of " var=value (,var=value)* " syntax but the actual semantics and
> possible value pairs are not specified. That is for all commands.

As for semantics, I have not made it this far ....

> Anyway, it looks weird if no rigorous specification of MI output
> exist. IMHO it means (if it is) that no one uses MI in real systems
> (except the tests and demo purposes)...

Well, if you plan on doing this, as I do, it would be helpful if there
were some place's in GDB's doco that we could contribute back information
that we think is helpful. 

Meaning if you need semantic information and then you find out about it,
document it somewhere in GDB. This information could be useful later on.
Especially if I ever get around to verifying the MI testsuite with an MI
parser. At that point, not only could we verify the syntax but we could
make sure some of the semantics are correct too.

Thanks,
Bob Rossi

Re: complete GDB MI specification

[Eli Zaretskii]

> Date: Tue, 7 Dec 2004 13:58:49 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> 
> Well, if you plan on doing this, as I do, it would be helpful if there
> were some place's in GDB's doco that we could contribute back information
> that we think is helpful. 

Sorry, I don't understand: what is ``back information'' that you are
talking about?  Why not simply add the documentation to the manual?

Re: complete GDB MI specification

[Bob Rossi]

On Tue, Dec 07, 2004 at 09:45:01PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 7 Dec 2004 13:58:49 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> > 
> > Well, if you plan on doing this, as I do, it would be helpful if there
> > were some place's in GDB's doco that we could contribute back information
> > that we think is helpful. 
> 
> Sorry, I don't understand: what is ``back information'' that you are
> talking about?  Why not simply add the documentation to the manual?

hehe, very sorry. Just bad English.

What I meant to say was, It would be helpful if there was a place in the
GDB manual that had all of the MI commands for specific versions of MI,
and all of the fields that the MI command is capable of outputting.
Basically, the semantic information needed to write a parser and quickly
interpret the MI commands as correct or incorrect output, and what each
field means.

Thanks,
Bob Rossi

Re: complete GDB MI specification

[Eli Zaretskii]

> Date: Tue, 7 Dec 2004 14:50:19 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: kostik@ispras.ru, gdb@sources.redhat.com
> 
> What I meant to say was, It would be helpful if there was a place in the
> GDB manual that had all of the MI commands for specific versions of MI,
> and all of the fields that the MI command is capable of outputting.
> Basically, the semantic information needed to write a parser and quickly
> interpret the MI commands as correct or incorrect output, and what each
> field means.

Such information, if we decide to include it, should go into
gdbint.texinfo.

But basically, I think that once the Yacc parser is written and
becomes part of GDB, we should maintain the parser instead of
documenting the grammar.

Re: complete GDB MI specification

[Eli Zaretskii]

> Date: Tue, 7 Dec 2004 21:44:36 +0300
> From: Konstantin Karganov <kostik@ispras.ru>
> CC: gdb@sources.redhat.com
> 
> "Note that the current ``grammar'' in the MI documentation, at least as
> far as I'm concerned, is meant to be an informal introduction of the
> MI syntax, not a rigurous grammar description.

This is known, of course.  Volunteers are welcome to rewrite the MI
documentation more rigorously.  I was happy enough to get my hands on
_any_ documentation, and needed to do non-trivial amounts of work to
bring it to the state where it could be integrated into gdb.texinfo.

> And this is the problem! MI is supposed to be a program-to-program
> interface and thus needs a complete formal description (at least, to be
> sure that all possible output is handled correctly).

I agree, but no one volunteered yet to produce such a formal
description.  (And I'm not sure such a description should be in the
manual, anyway.)

> Looked through several (a lot, actually!) discussions and didn't found
> what I need.

Sorry, I thought a grammar was posted, but perhaps I was mistaken.

> > Please report all such unclear cases, and I will try to fix them.
> Look at the structure of MI description: there are the command syntax
> with explanation and the example of the output. Just an example
> instead of complete output specification. Yes, it fits the general case
> of " var=value (,var=value)* " syntax but the actual semantics and
> possible value pairs are not specified. That is for all commands.

If an example is clear and tells enough to explain what to expect,
then it's fine by me.  If you find incorrect or misleading examples,
please point them out, and please tell what is misleading about them.
I appreciate your comments, but to fix the manual, I need them to be
more specific.

> Anyway, it looks weird if no rigorous specification of MI output
> exist. IMHO it means (if it is) that no one uses MI in real systems
> (except the tests and demo purposes)...

Rest assured that it _is_ used, in real-life systems.

Re[2]: complete GDB MI specification

[Konstantin Karganov]

Hello Eli,

>(And I'm not sure such a description should be in the manual, anyway.)
As for me, I think it should be in UG since it is a way to use GDB.
Maybe in appendix or some "advanced" chapter.

> Sorry, I thought a grammar was posted, but perhaps I was mistaken.
There was posted a refined grammar transformed to LL(1) kind, but
that's not exactly what is needed...

> If an example is clear and tells enough to explain what to expect,
> then it's fine by me.
It's fine to illustrate the point or get the main idea, but do not
suffice for writing a code that will use it automatically.
The text-based protocol for the debugger that we implemented 2 years
ago had _much_ more rigorous and complete specification.

> If you find incorrect or misleading examples, please point them out,
> and please tell what is misleading about them.
Oh, BTW, I've got one :)
Section 24.9 (GDB/MI Program control), subsection "The -exec-interrupt
command". The specified behavior doesn't reproduce since the
-exec-continue and other stepping commands are not asynchronous
(though the doc states they are).

> But basically, I think that once the Yacc parser is written and
> becomes part of GDB, we should maintain the parser instead of
> documenting the grammar.
Yes, I've also got this idea - it's better not to develop parsers
every time from the scratch, but to have a "standard" parser since it
fits the main goal of the MI interface project. In this case it can be
easily made consistent with current MI version (as supported by the
same team). Anyhow, the detailed semantics description of the parser
output should be available, here I completely disagree with the
position "maintain instead of documenting" (literally, as it was
mentioned).

One more question about this parser as a part of GDB - does it exist
and will be available or it's still a far distant project?

-- 
Best regards,
 Konstantin 

Re: complete GDB MI specification

[Bob Rossi]

> One more question about this parser as a part of GDB - does it exist
> and will be available or it's still a far distant project?

Well, this was something I want to do. I just will not have time for a
few months.

I do already have the grammar to yacc that will generate a parser. I
also have a sample main that will parse a single MI output command. The
problem is, it's untested and it is not integrated into the testsuite.

If you want to work on such a project, I could start you out with what I
have so far. If you want to wait, eventually I should have something. 
I already have a small goal of getting this in for 7.0, since that's
the version I hope to get my personal project integrated with GDB.

Thanks,
Bob Rossi

Re[2]: complete GDB MI specification

[Konstantin Karganov]

Hello Bob,

> I just will not have time for a few months.
> If you want to work on such a project, I could start you out with what I
> have so far.
It seems that I'll have to develop my own parser and refine the MI
response semantics to build a debugger over it.
Currently planning to use Boost Spirit parser generator.

> the simplest solution would be to provide a second yacc parser
And then a 3rd one to parse the 2nd, etc. Any volunteers? :)

-- 
Best regards,
 Konstantin 

Re: complete GDB MI specification

[Bob Rossi]

On Wed, Dec 08, 2004 at 08:48:01PM +0300, Konstantin Karganov wrote:
> Hello Bob,
> 
> > I just will not have time for a few months.
> > If you want to work on such a project, I could start you out with what I
> > have so far.
> It seems that I'll have to develop my own parser and refine the MI
> response semantics to build a debugger over it.
> Currently planning to use Boost Spirit parser generator.
> 
> > the simplest solution would be to provide a second yacc parser
> And then a 3rd one to parse the 2nd, etc. Any volunteers? :)

BTW, I also have an official grammar representation that I used to get
the yacc input for.

If that sounds interesting to you, I'll try to dig it up.

Bob Rossi

Re: complete GDB MI specification

[Bob Rossi]

On Wed, Dec 08, 2004 at 01:29:42PM -0500, Bob Rossi wrote:
> On Wed, Dec 08, 2004 at 08:48:01PM +0300, Konstantin Karganov wrote:
> > Hello Bob,
> > 
> > > I just will not have time for a few months.
> > > If you want to work on such a project, I could start you out with what I
> > > have so far.
> > It seems that I'll have to develop my own parser and refine the MI
> > response semantics to build a debugger over it.
> > Currently planning to use Boost Spirit parser generator.
> > 
> > > the simplest solution would be to provide a second yacc parser
> > And then a 3rd one to parse the 2nd, etc. Any volunteers? :)
> 
> BTW, I also have an official grammar representation that I used to get
> the yacc input for.
> 
> If that sounds interesting to you, I'll try to dig it up.

I'm to tired ...
I meant to say 'unofficial'.

Bob Rossi

Re[2]: complete GDB MI specification

[Konstantin Karganov]

Hello Bob,

> If that sounds interesting to you, I'll try to dig it up.
> I meant to say 'unofficial'.
Sounds interesting, might be usefull. Thanks in advance.

-- 
Best regards,
 Konstantin 

RE: Re[2]: complete GDB MI specification

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Konstantin Karganov
> Sent: 08 December 2004 16:45

> > But basically, I think that once the Yacc parser is written and
> > becomes part of GDB, we should maintain the parser instead of
> > documenting the grammar.
> Yes, I've also got this idea - it's better not to develop parsers
> every time from the scratch, but to have a "standard" parser since it
> fits the main goal of the MI interface project. In this case it can be
> easily made consistent with current MI version (as supported by the
> same team). Anyhow, the detailed semantics description of the parser
> output should be available, here I completely disagree with the
> position "maintain instead of documenting" (literally, as it was
> mentioned).


  Maybe the best solution would be to use one of those auto-documentation format
where comments in the source code for the parser are extracted and used to
generate the docs?  I quite like doxygen, but it's probably not the right tool
for this job: a) it would be yet another tool that developers would have to
install in addition to all the auto* tools etc., b) it's a rather overengineered
and heavyweight solution to the problem and c) it doesn't generate .texi output
(AFAIR, but don't quote me on that).

  Actually, maybe the simplest solution would be to provide a second yacc
parser, to parse the comments out of the first parser and output them in .texi
format so they can be included in the documentation build automatically....

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....