This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Questions about GDB/MI
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Nick Roberts <nick at nick dot uklinux dot net>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 4 Feb 2003 19:22:34 -0500
- Subject: Re: Questions about GDB/MI
- References: <15936.19654.642542.951794@nick.uklinux.net>
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