Re: gdb/mi

Re: gdb/mi

[Jim Ingham]

>
>
> On Wed, 10 Jul 2002, Greg Watson wrote:
>
>> Seems like Apple must have already fixed this in the MacOS X version
>> (which is 5.0). Here is the output from 'gdb -i mi' to prove it. :-)
>
> I've already fixed this in my branch, based on Apple's work:
>
> $ ./gdb --i=mi
> ~"GNU gdb 2002-06-19-cvs\n"
> ~"Copyright 2002 Free Software Foundation, Inc.\n"
> ~"GDB is free software, covered by the GNU General Public License, and 
> you are\n"
> ~"welcome to change it and/or distribute copies of it under certain 
> conditions.\n"
> ~"Type \"show copying\" to see the conditions.\n"
> ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for 
> details.\n"
> ~"This GDB was configured as \"i686-pc-linux-gnu\"."
> ~"\n"
> (gdb)
>
> We should see these changes rolling into mainline sources sometime in 
> the
> coming weeks. I've still a few anomalies to hammer out.

Cool!

>
>> Oh damn! I thought you'd already done the hard stuff and I could get
>> rid of the pty code from my front end. I guess that means that
>> asynchronous commands will only work with remote targets as well? Can
>> you point me at the approximate archive so I can review this
>> discussion?
>
> Yes, async on remotes only. I haven't even attempted to do this work 
> yet.
> I figure sync is good enough to get my MI project moving.

We use the async mode for the MacOS X native target.  It took a bit of 
thinking to get this right, partly because MacOS X itself is a little 
complicated (you have to talk both to mach & to the bsd layer...) and 
because there were many aspects of the async support that weren't fully 
worked out (like how exactly are user-defined & breakpoint commands 
going to work in async gdb...).  I also am pretty sure I broke remote 
async targets, there were some hacks involving who had the terminal in 
the remote async code which were wrong I am pretty sure (and the 
comments in the code indicated the original author suspected that as 
well) and kept our native async support from working.

But if you are interested, all the code is in the Darwin repository (or 
in opendarwin for those who would prefer not to give Apple their e-mail 
address)...

>
>> Do you know if there are any plans to handle native output within the
>> mi syntax, or would you be interested in someone adding this
>> functionality, or is it likely to be too difficult?
>
> If you want to help, we could use the help. I don't think anyone is
> even thinking about how to do this yet, so almost anything is better 
> than
> nothing. The solution to this problem is almost certainly going to 
> differ
> from system to system, but we've got to start somewhere IMO.

Not sure here.  We switched ProjectBuilder over to using a separate tty 
for program output, it wasn't that hard to do, and it makes life just 
SO much easier.  So while it would be great if somebody was going to 
put the work into separating the output, given how easy the workaround 
is, it would be way way down on my list of things to do...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

GDB/MI

[Nick Roberts]

The debugger mode that uses GDB/MI which I am trying to write for Emacs uses a
queue but I can't get it initialised properly. This is why:

If I start with gdb -interp=mi mytest, I get

~"GNU gdb 2003-02-04-cvs\n"
~"Copyright 2003 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i586-pc-linux-gnu\"..."
~"\n"
(gdb) 

I see that the text is now escaped with ~ so I know this is output for the
console. However, Emacs don't know that GDB is ready for input. With level 2
annotations, I get:

GNU gdb 2003-02-04-cvs
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu"...
breakpoints-invalid

^Z^Zframes-invalid


^Z^Zpre-prompt
(gdb) 
^Z^Zprompt

and the prompt annotation tells Emacs that GDB is ready for input. Since Emacs'
interaction is asynchronous, the timing is wrong if I assume GDB is ready for
input immediately after its invocation. I think the initial output should be:

~"GNU gdb 2003-02-04-cvs\n"
~"Copyright 2003 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i586-pc-linux-gnu\"..."
~"\n"
^done
(gdb) 

i.e GDB should notify its status with the ^done record.

I could look for the prompt (gdb) for notification and I imagine this is what
gvd does but the idea presumably is to have a machine interface and not rely
on output intended for the (human) user. For example this could be defeated
with `set prompt'.

I will file a bug report if someone agrees with my analysis.

Nick

Incidently, the string (gdb) that is output here is not the prompt but an
imposter as I get:

-gdb-set prompt (hec)
^done
(gdb) 
-gdb-show prompt
^done,value="(hec)"
(gdb) 

Re: GDB/MI

[Andrew Cagney]

> The debugger mode that uses GDB/MI which I am trying to write for Emacs uses a
> queue but I can't get it initialised properly. This is why:
> 
> If I start with gdb -interp=mi mytest, I get
> 
> ~"GNU gdb 2003-02-04-cvs\n"
> ~"Copyright 2003 Free Software Foundation, Inc.\n"
> ~"GDB is free software, covered by the GNU General Public License, and you are\n"
> ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
> ~"Type \"show copying\" to see the conditions.\n"
> ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
> ~"This GDB was configured as \"i586-pc-linux-gnu\"..."
> ~"\n"
> (gdb) 

The prompt:

	"(gdb)\n"

indicates that GDB is ready for input.  That prompt terminates every 
transaction.  It is independant of the console GDB prompt:

(gdb)
-interpreter-exec console set prompt foo
&"Argument required (expression to compute).\n"
^error,msg="Argument required (expression to compute)."
(gdb)
-interpreter-exec console "set prompt foo"
^done
(gdb)
-interpreter-exec console "show prompt"
~"Gdb's prompt is \"foo\".\n"
^done
(gdb)

There is a `bug' here - GDB should generate a `=prompt-changed' event.

Andrew


> ^Z^Zpre-prompt
> (gdb) 
> ^Z^Zprompt
> 
> and the prompt annotation tells Emacs that GDB is ready for input. Since Emacs'
> interaction is asynchronous, the timing is wrong if I assume GDB is ready for
> input immediately after its invocation. I think the initial output should be:
> 
> ~"GNU gdb 2003-02-04-cvs\n"
> ~"Copyright 2003 Free Software Foundation, Inc.\n"
> ~"GDB is free software, covered by the GNU General Public License, and you are\n"
> ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
> ~"Type \"show copying\" to see the conditions.\n"
> ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
> ~"This GDB was configured as \"i586-pc-linux-gnu\"..."
> ~"\n"
> ^done
> (gdb) 
> 
> i.e GDB should notify its status with the ^done record.
> 
> I could look for the prompt (gdb) for notification and I imagine this is what
> gvd does but the idea presumably is to have a machine interface and not rely
> on output intended for the (human) user. For example this could be defeated
> with `set prompt'.
> 
> I will file a bug report if someone agrees with my analysis.
> 
> Nick
> 
> Incidently, the string (gdb) that is output here is not the prompt but an
> imposter as I get:
> 
> -gdb-set prompt (hec)
> ^done
> (gdb) 
> -gdb-show prompt
> ^done,value="(hec)"
> (gdb) 
> 

Re: GDB/MI

[Nick Roberts]

> The prompt:
> 
> 	"(gdb)\n"
> 
> indicates that GDB is ready for input.  That prompt terminates every 
> transaction.  It is independant of the console GDB prompt:

It looks very like the console GDB prompt and could cause confusion so perhaps
it could be replaced with something like "(mi)\n".

If "(gdb)\n" is an invariant (the user can't change it) then that would be
fine except that, debugging a program with output I get:

...
(gdb) 
-exec-run
^running
(gdb) 
Enter no. of iterations:

and "(gdb)\n" is output but GDB *not* ready for input, the inferior is. This
is the extra "(gdb)\n" that I talked about earlier with Elena as in:

-exec-run
^running
(gdb) 
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x0804856c",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff7f4"}],file="mytest.c",line="36"}
(gdb) 

According to the current documentation for the GDB/MI Output Syntax
--------------------, the first
"(gdb)\n" should not be output.

> (gdb)
> -interpreter-exec console set prompt foo
> &"Argument required (expression to compute).\n"
> ^error,msg="Argument required (expression to compute)."
> (gdb)
> -interpreter-exec console "set prompt foo"
> ^done
> (gdb)
> -interpreter-exec console "show prompt"
> ~"Gdb's prompt is \"foo\".\n"
> ^done
> (gdb)
> 
> There is a `bug' here - GDB should generate a `=prompt-changed' event.

I can't find any reference to such an event but if MI has its own prompt
then maybe its not needed.

Nick

Re: GDB/MI

[Eli Zaretskii]

> Date: Thu, 20 Feb 2003 20:49:46 -0500
> From: Andrew Cagney <ac131313@redhat.com>
> 
> The prompt:
> 
> 	"(gdb)\n"
> 
> indicates that GDB is ready for input.

If this is so, we should say that in the MI manual, I think.

Re: GDB/MI

[Andrew Cagney]

>> Date: Thu, 20 Feb 2003 20:49:46 -0500
>> From: Andrew Cagney <ac131313@redhat.com>
>> 
>> The prompt:
>> 
>> 	"(gdb)\n"
>> 
>> indicates that GDB is ready for input.
> 
> 
> If this is so, we should say that in the MI manual, I think.

http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC223
The output from GDB/MI consists of zero or more out-of-band records 
followed, optionally, by a single result record. This result record is 
for the most recent command. The sequence of output records is 
terminated by `(gdb)'.

Andrew

gdb/mi

[Greg Watson]

I have some questions/comments about gdb/mi if someone could help out:

1. I've configure gdb 5.2 with --enable-gdbmi and --with-uiout. 
However when I run "gdb --interpreter=mi" the initial messages are 
not in console stream output format, but later messages are. Is this 
by design?

2. When I run a target program, it's output is not in target stream 
output format. Should this be the case?

3. The gdb/mi output syntax in the manual does not quite reflect 
reality. In particular the 'console-stream-output', 
'target-stream-output' and 'log-stream-output' rules should be 
suffixed with 'nl'.  Also, I've observed an 'out-of-band-record' 
appearing after a 'result-record' but the syntax doesn't allow this. 
I guess it should be something like:

output -> (out-of-band-record)* [result-record] (out-of-band-record)* 
"(gdb)" nl


Regards,

Greg

Re: gdb/mi

[Andrew Cagney]

> I have some questions/comments about gdb/mi if someone could help out:
> 
> 1. I've configure gdb 5.2 with --enable-gdbmi and --with-uiout. However when I run "gdb --interpreter=mi" the initial messages are not in console stream output format, but later messages are. Is this by design?

You mean the (C) startup message?  No one has thought about that.
(BTW, you no longer need to explicitly configure in GDB/MI, since 5.2, 
it has been enabled by default).

> 2. When I run a target program, it's output is not in target stream output format. Should this be the case?

It depends.

This is a problem that has been discussed before on this list.  If the 
target program is native then GDB would need to do something like play 
with pty's or start a separate terminal program.  If the target is 
remote then the output being encapsulated depends on support for this in 
the remote protocol.

> 3. The gdb/mi output syntax in the manual does not quite reflect reality. In particular the 'console-stream-output', 'target-stream-output' and 'log-stream-output' rules should be suffixed with 'nl'.  Also, I've observed an 'out-of-band-record' appearing after a 'result-record' but the syntax doesn't allow this. I guess it should be something like:
> 
> output -> (out-of-band-record)* [result-record] (out-of-band-record)* "(gdb)" nl

Yes (but I'll fix it a different way).  Good catch.

Andrew

Re: gdb/mi

[Greg Watson]

>>I have some questions/comments about gdb/mi if someone could help out:
>>
>>1. I've configure gdb 5.2 with --enable-gdbmi and --with-uiout. 
>>However when I run "gdb --interpreter=mi" the initial messages are 
>>not in console stream output format, but later messages are. Is 
>>this by design?
>
>You mean the (C) startup message?  No one has thought about that.
>(BTW, you no longer need to explicitly configure in GDB/MI, since 
>5.2, it has been enabled by default).

Seems like Apple must have already fixed this in the MacOS X version 
(which is 5.0). Here is the output from 'gdb -i mi' to prove it. :-)

~"GNU gdb 5.0 (Thu Jun 20 15:19:17 GMT 2002)\n"
~"Copyright 2002 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, 
and you are\n"
~"welcome to change it and/or distribute copies of it under certain 
conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" 
for details.\n"
~"This GDB was configured as \"powerpc-apple-darwin5.5\".\n"
~"Setting up the environment for debugging gdb.\n"

>>2. When I run a target program, it's output is not in target stream 
>>output format. Should this be the case?
>
>It depends.
>
>This is a problem that has been discussed before on this list.  If 
>the target program is native then GDB would need to do something 
>like play with pty's or start a separate terminal program.  If the 
>target is remote then the output being encapsulated depends on 
>support for this in the remote protocol.

Oh damn! I thought you'd already done the hard stuff and I could get 
rid of the pty code from my front end. I guess that means that 
asynchronous commands will only work with remote targets as well? Can 
you point me at the approximate archive so I can review this 
discussion?

>
>>3. The gdb/mi output syntax in the manual does not quite reflect 
>>reality. In particular the 'console-stream-output', 
>>'target-stream-output' and 'log-stream-output' rules should be 
>>suffixed with 'nl'.  Also, I've observed an 'out-of-band-record' 
>>appearing after a 'result-record' but the syntax doesn't allow 
>>this. I guess it should be something like:
>>
>>output -> (out-of-band-record)* [result-record] 
>>(out-of-band-record)* "(gdb)" nl
>
>Yes (but I'll fix it a different way).  Good catch.

If you're going to allow general program output to be intermingled 
with the mi output then this should probably also be reflected in the 
syntax.

Do you know if there are any plans to handle native output within the 
mi syntax, or would you be interested in someone adding this 
functionality, or is it likely to be too difficult?

Cheers,

Greg

Re: gdb/mi

[Keith Seitz]

On Wed, 10 Jul 2002, Greg Watson wrote:

> Seems like Apple must have already fixed this in the MacOS X version
> (which is 5.0). Here is the output from 'gdb -i mi' to prove it. :-)

I've already fixed this in my branch, based on Apple's work:

$ ./gdb --i=mi
~"GNU gdb 2002-06-19-cvs\n"
~"Copyright 2002 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i686-pc-linux-gnu\"."
~"\n"
(gdb)

We should see these changes rolling into mainline sources sometime in the
coming weeks. I've still a few anomalies to hammer out.

> Oh damn! I thought you'd already done the hard stuff and I could get
> rid of the pty code from my front end. I guess that means that
> asynchronous commands will only work with remote targets as well? Can
> you point me at the approximate archive so I can review this
> discussion?

Yes, async on remotes only. I haven't even attempted to do this work yet.
I figure sync is good enough to get my MI project moving.

> Do you know if there are any plans to handle native output within the
> mi syntax, or would you be interested in someone adding this
> functionality, or is it likely to be too difficult?

If you want to help, we could use the help. I don't think anyone is
even thinking about how to do this yet, so almost anything is better than
nothing. The solution to this problem is almost certainly going to differ
from system to system, but we've got to start somewhere IMO.

Keith