Questions about GDB/MI

Questions about GDB/MI

[Nick Roberts]

I'm trying to get my head round GDB/MI and have a few simple/dumb questions:

Simple example in info pages:

You say:

>    -> -stop
>    <- (gdb)
> 
> and later: 
>
>    <- *stop,reason="stop",address="0x123",source="a.c:123"
>    <- (gdb)

I get:

-> -stop
<- ^error,msg="Undefined MI command: stop"
<- (gdb) 

You say:

>     -> print 1+2
>     <- ~3\n
>     <- (gdb)

I get:

-> print 1+2
<- &"print 1+2\n"
<- ~"$1 = 3"
<- ~"\n"
<- ^done
<- (gdb) 

Running a simple program, I get a sequence like:

-> -exec-next
<- ^running
<- (gdb) 
<- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
<- (gdb) 

According to the GDB/MI Output Syntax shouldn't that be:

-> -exec-next
<- ^running
<- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
<- (gdb) 

i.e isn't that one (gdb) too many?

My simple program prints out:

a[0]=0

shouldn't that be:

@"a[0]=0"

Annotation uses ^Z^Z to flag things which I guess is not normal output. What
would happen if the program being debugged printed out strings like *stopped
or ^running? These only contain ASCII characters after all.

And one question about the repository. I've checked out as Elena advised. I've
got the interp branch but every time I use `cvs update' in src, even without
the -d option it keeps on trying to give me other directories like binutils. I
have to go into gdb and do `cvs update' there where I just get gdbtk but I'm
worried that then I might be missing other files that I need..

Nick

Re: Questions about GDB/MI

[Elena Zannoni]

Nick Roberts writes:
 > 
 > I'm trying to get my head round GDB/MI and have a few simple/dumb questions:
 > 
 > Simple example in info pages:
 > 
 > You say:
 > 
 > >    -> -stop
 > >    <- (gdb)
 > > 
 > > and later: 
 > >
 > >    <- *stop,reason="stop",address="0x123",source="a.c:123"
 > >    <- (gdb)
 > 
 > I get:
 > 
 > -> -stop
 > <- ^error,msg="Undefined MI command: stop"
 > <- (gdb) 
 > 

Hmmm, bogus docs. 'stop' as a command hasn't been implemented. There
is a comment in the .texinfo file about this. The command that does this is 
available only on async targets (remote), and is called exec-interrupt.

Could you file a bug report?

 > You say:
 > 
 > >     -> print 1+2
 > >     <- ~3\n
 > >     <- (gdb)
 > 
 > I get:
 > 
 > -> print 1+2
 > <- &"print 1+2\n"
 > <- ~"$1 = 3"
 > <- ~"\n"
 > <- ^done
 > <- (gdb) 
 > 

Are you lookng at html or ps?  In the .texinfo file the text is
correct, it is just not formatted properly:

@example
-> print 1+2
<- &"print 1+2\n"
<- ~"$1 = 3\n"
<- ^done
<- (@value{GDBP})
@end example

could you file another bug report?


 > Running a simple program, I get a sequence like:
 > 
 > -> -exec-next
 > <- ^running
 > <- (gdb) 
 > <- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
 > <- (gdb) 
 > 
 > According to the GDB/MI Output Syntax shouldn't that be:
 > 
 > -> -exec-next
 > <- ^running
 > <- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
 > <- (gdb) 
 > 
 > i.e isn't that one (gdb) too many?
 > 

I get the extra prompt too. Are you running on a native target?
Or on a remote target? On a remote target, the async capability of gdb
when running the inferior is real (if using 'target async'), while on
native, it is simulated. I wonder if there is a mismatch somewhere.
Anyway, if you are just running natively, it may be simply another doc
error.

Some of the documentation was written before we implemented the
commands, it evolved from a design doc into a user guide.

 > My simple program prints out:
 > 
 > a[0]=0
 > 
 > shouldn't that be:
 > 
 > @"a[0]=0"
 > 

Don't remember what the status of this is. Look through the bugs
database, for open MI bugs. But I see a testcase in the testsuite, and
code in the mi directory, so it should work.

 > Annotation uses ^Z^Z to flag things which I guess is not normal output. What
 > would happen if the program being debugged printed out strings like *stopped
 > or ^running? These only contain ASCII characters after all.
 > 

we added the number prefixes to the command, to help in cases like these
if you say:
222-exec-next
you would get
222^running
222*stopped

and you can match them.

 > And one question about the repository. I've checked out as Elena advised. I've
 > got the interp branch but every time I use `cvs update' in src, even without
 > the -d option it keeps on trying to give me other directories like binutils. I
 > have to go into gdb and do `cvs update' there where I just get gdbtk but I'm
 > worried that then I might be missing other files that I need..
 > 

yes, update -d at the top level brings in everything in the
repository, i.e.  ignores the fact you checked out just a single
module.  Use cvs update -dP (P prunes empty directories) in the gdb
directory. But if you followed the instructions from the web site, you
should have everything.

elena


 > Nick

Re: Questions about GDB/MI

[Daniel Jacobowitz]

On Tue, Feb 04, 2003 at 07:22:34PM -0500, Elena Zannoni wrote:
> Nick Roberts writes:
>  > My simple program prints out:
>  > 
>  > a[0]=0
>  > 
>  > shouldn't that be:
>  > 
>  > @"a[0]=0"
>  > 
> 
> Don't remember what the status of this is. Look through the bugs
> database, for open MI bugs. But I see a testcase in the testsuite, and
> code in the mi directory, so it should work.

That's a nebulous "should".  It hasn't been implemented yet.

> 
>  > Annotation uses ^Z^Z to flag things which I guess is not normal output. What
>  > would happen if the program being debugged printed out strings like *stopped
>  > or ^running? These only contain ASCII characters after all.

Once it is implemented, then the program's output would all be escaped.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Questions about GDB/MI

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Tue, Feb 04, 2003 at 07:22:34PM -0500, Elena Zannoni wrote:
 > > Nick Roberts writes:
 > >  > My simple program prints out:
 > >  > 
 > >  > a[0]=0
 > >  > 
 > >  > shouldn't that be:
 > >  > 
 > >  > @"a[0]=0"
 > >  > 
 > > 
 > > Don't remember what the status of this is. Look through the bugs
 > > database, for open MI bugs. But I see a testcase in the testsuite, and
 > > code in the mi directory, so it should work.
 > 
 > That's a nebulous "should".  It hasn't been implemented yet.
 > 

This works with remote targets for SID and redboot.  It doesn't work
for native and targets that don't channel the printf's output to gdb.

 > > 
 > >  > Annotation uses ^Z^Z to flag things which I guess is not normal output. What
 > >  > would happen if the program being debugged printed out strings like *stopped
 > >  > or ^running? These only contain ASCII characters after all.
 > 
 > Once it is implemented, then the program's output would all be escaped.
 > 

Once it is implemented for natives.

 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: Questions about GDB/MI

[Nick Roberts]

 ...
 >  > I get:
 >  > 
 >  > -> -stop
 >  > <- ^error,msg="Undefined MI command: stop"
 >  > <- (gdb) 
 >  > 
 > 
 > Hmmm, bogus docs. 'stop' as a command hasn't been implemented. There
 > is a comment in the .texinfo file about this. The command that does this is 
 > available only on async targets (remote), and is called exec-interrupt.
 > 
 > Could you file a bug report?

I have done this.

 ...
 > Are you lookng at html or ps?  In the .texinfo file the text is
 > correct, it is just not formatted properly:
 > 
 > @example
 > -> print 1+2
 > <- &"print 1+2\n"
 > <- ~"$1 = 3\n"
 > <- ^done
 > <- (@value{GDBP})
 > @end example
 > 
 > could you file another bug report?

This was my mistake. I'm now looking at the *current* documentation.

 >  > Running a simple program, I get a sequence like:
 >  > 
 >  > -> -exec-next
 >  > <- ^running
 >  > <- (gdb) 
 >  > <- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
 >  > <- (gdb) 
 ...
 >  > 
 >  > i.e isn't that one (gdb) too many?
 >  > 
 > 
 > I get the extra prompt too. Are you running on a native target?
 > Or on a remote target? On a remote target, the async capability of gdb
 > when running the inferior is real (if using 'target async'), while on
 > native, it is simulated. I wonder if there is a mismatch somewhere.
 > Anyway, if you are just running natively, it may be simply another doc
 > error.
 > 

 I'm doing everything on one machine (=native?) but I don't see how this
 makes it a doc error unless there are *meant* to be two (gdb)'s for native
 and one for remote targets.

 > Some of the documentation was written before we implemented the
 > commands, it evolved from a design doc into a user guide.
 > 
 >  > My simple program prints out:
 >  > 
 >  > a[0]=0
 >  > 
 >  > shouldn't that be:
 >  > 
 >  > @"a[0]=0"

 > Don't remember what the status of this is. Look through the bugs
 > database, for open MI bugs. But I see a testcase in the testsuite, and
 > code in the mi directory, so it should work.

This seems a pretty fundamental requirement. If it doesn't work, for native
targets say, how does Project Builder do stream separation in these cases?

 >  > Annotation uses ^Z^Z to flag things which I guess is not normal
 >  > output. What would happen if the program being debugged printed out
 >  > strings like *stopped or ^running? These only contain ASCII characters
 >  > after all.
 >  > 
 > 
 > we added the number prefixes to the command, to help in cases like these
 > if you say:
 > 222-exec-next
 > you would get
 > 222^running
 > 222*stopped

Hmm. I'm not sure how I would use that as a strategy. But, as Daniel Jacobowitz
points out , if program's output is always escaped with the prefix above, there
may not be a problem.

 >  >                      ...every time I use `cvs update' in src, even
 >  > without the -d option it keeps on trying to give me other directories
 >  > like binutils. I have to go into gdb and do `cvs update' there where I
 >  > just get gdbtk but I'm worried that then I might be missing other files
 >  > that I need..
 >  > 
 > 
 > yes, update -d at the top level brings in everything in the
 > repository, i.e.  ignores the fact you checked out just a single
 > module.  Use cvs update -dP (P prunes empty directories) in the gdb
 > directory. But if you followed the instructions from the web site, you
 > should have everything.

But I've not used -d. If I follow the instructions from the web site, it appears
that I *do* get everything but I just want gdb.

I hope that I sound confused rather than ungrateful.

Thanks for your help.

Nick

Re: Questions about GDB/MI

[Elena Zannoni]

Nick Roberts writes:
 > 
 >  ...
 >  >  > I get:
 >  >  > 
 >  >  > -> -stop
 >  >  > <- ^error,msg="Undefined MI command: stop"
 >  >  > <- (gdb) 
 >  >  > 
 >  > 
 >  > Hmmm, bogus docs. 'stop' as a command hasn't been implemented. There
 >  > is a comment in the .texinfo file about this. The command that does this is 
 >  > available only on async targets (remote), and is called exec-interrupt.
 >  > 
 >  > Could you file a bug report?
 > 
 > I have done this.
 > 

thanks

 >  ...
 >  > Are you lookng at html or ps?  In the .texinfo file the text is
 >  > correct, it is just not formatted properly:
 >  > 
 >  > @example
 >  > -> print 1+2
 >  > <- &"print 1+2\n"
 >  > <- ~"$1 = 3\n"
 >  > <- ^done
 >  > <- (@value{GDBP})
 >  > @end example
 >  > 
 >  > could you file another bug report?
 > 
 > This was my mistake. I'm now looking at the *current* documentation.

ok

 > 
 >  >  > Running a simple program, I get a sequence like:
 >  >  > 
 >  >  > -> -exec-next
 >  >  > <- ^running
 >  >  > <- (gdb) 
 >  >  > <- *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x08048578",func="main",args=[],file="myprog.c",line="18"}
 >  >  > <- (gdb) 
 >  ...
 >  >  > 
 >  >  > i.e isn't that one (gdb) too many?
 >  >  > 
 >  > 
 >  > I get the extra prompt too. Are you running on a native target?
 >  > Or on a remote target? On a remote target, the async capability of gdb
 >  > when running the inferior is real (if using 'target async'), while on
 >  > native, it is simulated. I wonder if there is a mismatch somewhere.
 >  > Anyway, if you are just running natively, it may be simply another doc
 >  > error.
 >  > 
 > 
 >  I'm doing everything on one machine (=native?) but I don't see how this
 >  makes it a doc error unless there are *meant* to be two (gdb)'s for native
 >  and one for remote targets.
 >

Yes, I think there really should be 2 prompts, ie the doc is wrong.
 
 >  > Some of the documentation was written before we implemented the
 >  > commands, it evolved from a design doc into a user guide.
 >  > 
 >  >  > My simple program prints out:
 >  >  > 
 >  >  > a[0]=0
 >  >  > 
 >  >  > shouldn't that be:
 >  >  > 
 >  >  > @"a[0]=0"
 > 
 >  > Don't remember what the status of this is. Look through the bugs
 >  > database, for open MI bugs. But I see a testcase in the testsuite, and
 >  > code in the mi directory, so it should work.
 > 
 > This seems a pretty fundamental requirement. If it doesn't work, for native
 > targets say, how does Project Builder do stream separation in these cases?
 > 

I am not sure what they did, but you can match the numbers for the commands
as an interim solution.


 >  >  > Annotation uses ^Z^Z to flag things which I guess is not normal
 >  >  > output. What would happen if the program being debugged printed out
 >  >  > strings like *stopped or ^running? These only contain ASCII characters
 >  >  > after all.
 >  >  > 
 >  > 
 >  > we added the number prefixes to the command, to help in cases like these
 >  > if you say:
 >  > 222-exec-next
 >  > you would get
 >  > 222^running
 >  > 222*stopped
 > 
 > Hmm. I'm not sure how I would use that as a strategy. But, as Daniel Jacobowitz
 > points out , if program's output is always escaped with the prefix above, there
 > may not be a problem.

when you issue am mi command you prefix it by a number. All the
repliees to that command from gdb will be prefixed with the same
number. Look at the testsuite scripts for examples.

 > 
 >  >  >                      ...every time I use `cvs update' in src, even
 >  >  > without the -d option it keeps on trying to give me other directories
 >  >  > like binutils. I have to go into gdb and do `cvs update' there where I
 >  >  > just get gdbtk but I'm worried that then I might be missing other files
 >  >  > that I need..
 >  >  > 
 >  > 
 >  > yes, update -d at the top level brings in everything in the
 >  > repository, i.e.  ignores the fact you checked out just a single
 >  > module.  Use cvs update -dP (P prunes empty directories) in the gdb
 >  > directory. But if you followed the instructions from the web site, you
 >  > should have everything.
 > 
 > But I've not used -d. If I follow the instructions from the web site, it appears
 > that I *do* get everything but I just want gdb.
 > 

I misread what you said.  What's your directory structure?  Do you
have 'src' as the top directory?  the you should have bfd, config,
libiberty, readline, opcodes, sim, tcl, texinfo, gdb as sudirectories.

Just to be sure, is this what you did?

cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
       {enter "anoncvs" as the password}
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src co gdb+dejagnu

cd src
cvs update

I just did this myself, and didn't see anything odd.

elena



 > I hope that I sound confused rather than ungrateful.
 > 
 > Thanks for your help.
 > 
 > Nick

Re: Questions about GDB/MI

[Jim Blandy]

Nick Roberts <nick@nick.uklinux.net> writes:
> My simple program prints out:
> 
> a[0]=0
> 
> shouldn't that be:
> 
> @"a[0]=0"

MI doesn't yet capture all the output of the inferior; I mentioned
this in my first message.  One approach is to use GDB's 'tty' command
to have the inferior run on a different tty than GDB itself.  gdb-ui
can create a separate process buffer for the inferior's I/O, call
process-tty-name to get the name of its pseudo-tty, and then pass that
to GDB's 'tty' command.

I've never done this myself, mind you.  The last time I used the 'tty'
command was probably ten years ago or so, to debug Emacs redisplay
bugs.

Re: Questions about GDB/MI

[Elena Zannoni]

Jim Blandy writes:
 > 
 > Nick Roberts <nick@nick.uklinux.net> writes:
 > > My simple program prints out:
 > > 
 > > a[0]=0
 > > 
 > > shouldn't that be:
 > > 
 > > @"a[0]=0"
 > 
 > MI doesn't yet capture all the output of the inferior; I mentioned
 > this in my first message.  One approach is to use GDB's 'tty' command
 > to have the inferior run on a different tty than GDB itself.  gdb-ui
 > can create a separate process buffer for the inferior's I/O, call
 > process-tty-name to get the name of its pseudo-tty, and then pass that
 > to GDB's 'tty' command.
 > 
 > I've never done this myself, mind you.  The last time I used the 'tty'
 > command was probably ten years ago or so, to debug Emacs redisplay
 > bugs.

As I said, it works with SID and embedded targets running redboot.

GDB/MI stream separation

[Nick Roberts]

Jim Blandy wrote:

 >                        ...One approach is to use GDB's 'tty' command
 > to have the inferior run on a different tty than GDB itself.  gdb-ui
 > can create a separate process buffer for the inferior's I/O, call
 > process-tty-name to get the name of its pseudo-tty, and then pass that
 > to GDB's 'tty' command.

I have only seen the tty command work in one direction. That is, I can send
the inferior's output to another terminal/buffer easily enough but I can't
seem to receive its input. I could, however, do omething like:

(defun io-mode ()
  "Major mode for io.

\\{comint-mode-map}"
  (make-comint "io-process""/bin/cat")
  (setq major-mode 'io-mode)
  (setq mode-name "Debuggee I/O")
  (setq comint-input-sender 'io-sender))

(defun io-sender (proc string)
  (let ((gud-proc (get-buffer-process  gud-comint-buffer)))
  (save-excursion
    (set-buffer (process-buffer gud-proc))
    (process-send-string gud-proc string)
    (process-send-string gud-proc "\n"))))

(gud-def gud-run (concat "-exec-run > " 
			 (process-tty-name (get-process "io-process"))))

so that `>' sends the inferior's output to another buffer and
process-send-string sends the inferior's input back to GDB. This would
not work if the run command was passed to GDB through the GUD buffer.

Stream separation might not be essential but it would be nice to do if there's
an easy way.

Nick