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: Questions about GDB/MI


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


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