Re: [cdt-debug-dev] debug gdb/mi updates

["Alain Magloire" <alain@xxxxxxx>]

> 
> On Wed, 21 Aug 2002, Alain Magloire wrote:
> 
> > 
> > 	A short update on the debug front(...cdt.debug.*).
> > We have the basic framework in place, with the current code-base
> > one can now, step/next, see the stackframe and the variables in the
> > variable view.  It requires gdb-5.2.1(gdb/mi).
> 
> Great news! Cannot wait to play with it!
> 

It is in the works, something should be coming down the pipe shortly.

> > For GNU/Linux: the parse will break since the target outputs are not
> >                properly wrap in gdb/mi
> 
> Someone should be working on this very soon, unless you want some of the 
> below things fixed first (which I suspect you might).

8-)

> 
> > - The syntax says:
> > 
> > 	OUTPUT ==> (OUT-OF-BAND-RECORD)* [RESULT-RECORD] "(gdb)"nl
> > 
> > Which seems to imply that a gdb/mi output is zero or more out-of-bands
> > that can be followed by an optionnal resul-record and the termination
> > string "(gdb)\n".  But the output is more this:
> > 
> > 	OUTPUT ==> (OUT-OF-BAND-RECORD)* | [RESULT-RECORD] "(gdb)"nl
> > 
> > Out-of-bands can come at any time and are not necessarly followed by "(gdb)\n"
> 
> Hmmm. I haven't seen this yet. If you can find a specific case of this, 
> please submit a bug to GDB's public bug database so that we don't forget 
> about it.

I do not think it is a bug per say.  For example this:

1:int main() {
2:	int x;
3:	pthread_create(NULL, NULL, routine, NULL);
4:	printf("Hello world\n");
5:	sleep(200000); // Or a very time consuming function called.
6:	printf("After the long wait\n");
7:	return 0;
8:}

gdb/mi will issue things like:
(gdb)
-break-insert file.c:6
^done,bkpt={...}
~"[New Thread 1024 (LWP 30497)]\n"
~"[Switching to Thread 1024 (LWP 30497)]\n"
.... wait for the sleep ....
*stopped,reason=...
(gdb)

You do not have the "(gdb)" comming right away.

	OUTPUT ==> (OUT-OF-BAND-RECORD)* [RESULT-RECORD] "(gdb)"nl

I read the definition like you can accumulate outputs and deal with them only
when encounter "(gdb)"  which is true unless you want to wait for the sleep() to
finish.  In practice we can consider Out-of-band completely async and should be
process right away.  It was not clear at first sight, IMHO.


> 
> [BTW, one thing you're going to find is that MI is changing quite a bit 
> right now. You're going to see a LOT more out-of-band records.]
>  

8-)  That's good, if they have a formal syntax, meaning not merely a console stream
but rather mi syntax so to not have ad-hoc parsing for each oob. 
  For example, this oob
	~"[Switching to Thread 1024 (LWP 30497)]\n"
is useless.  But if it is:
	*switch,new-thread-id="4",old-thread-id="1"
now that's kosher.

> > - var-update syntax is:
> > 
> > 	^done,changelist={name="var3",in_scope="true",type_changed="false",
> > 	 name="var2",in_scope="true",type_changed="false"}
> > 
> > how about taking advantabe of the MI List:
> > 
> > 	^done,changelist=[{name="var3",in_scope="true",type_changed="false"},
> > 	 {name="var2",in_scope="true",type_changed="false"}]
> > 
> > which will regroup every object updates.
> 
> File a bug on this, please.
> 

Ok, we'll do later, with some others.

> > - Breaks,  there is no way to use gdb cli-command "condition" to change
> >   the condition of an mi -break-insert. Something like -break-condition
> >   would be nice.
> 
> Hmm. There is a break-condition command already:
> 
> $ ./gdb -i=mi -nx -q
> (gdb)
> -file-exec-and-symbols gdb
> =architecture-changed
> ^done
> (gdb)
> -break-insert main
> =breakpoint-create,number="1"
> ^done
> (gdb)
> -break-condition 1 argc==2
> =breakpoint-modify,number="1"
> ^done
> (gdb)
> -interpreter-exec console "info break"
> ~"Num Type           Disp Enb Address    What\n"
> ~"1   breakpoint     keep y   0x08074fc6 in main at 
> ../../src/gdb/main.c:743\n"
> ~"\tstop only if argc == 2\n"
> ^done
> (gdb)


__Very__ sexy!!
Funny, somehow I've missed it.

> 
> > - For temporary breaks, when the async oob comes it does not give the 
> >   bpt number back.
> 
> It won't do this anymore anyway, so exepct to make this change:
> 
> -break-insert -t captured_main
> =breakpoint-create,number="2"
> ^done
> (gdb)

-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
addr="0x0804857e",func="main",file="thread.c",line="16",times="0"}

Is the above format gone? or deprecated for the future?


> > - Some inconsitencies in the outputs; different when a mi result-record
> >   then when a mi oob, althought they carry the same information.
> 
> Probably. When you find specific cases of them, please submit a bug.

info threads
-thread-list-ids

For example, on solaris and qnx, -thread-list-ids only shows the _current_
threads.  It is necessary to first do "info threads" in order to get the
right output from -thread-list-ids.

> 
> > - no way to know what thread is selected when doing -thread-list-ids, you
> >   have to fall back to "info threads"
> 
> Missing implementation. Submit bug.
> 
> > - some infos are only available to console-stream so you have to do some ad-hoc
> >   parsing on top of mi parsing.
> 
> Submit but with specific examples.
> 
> > - different kind of answer when using cli instead of mi.
> 
> You mean if you use the cli command instead of the mi command? Don't use 
> the CLI command. If something is missing, submit a bug. The cli command 
> stuff is a hack that was used to facilitate early adoption. Well, that 
> time has long passed, and it's time for that stuff to go.

Good move, IMHO.

> 
> > Event with all of the annoyances 5.2.1 gdb/mi is a step in the right direction.
> 
> I am happy to see MI finally get some use/review. It is important now 
> that all the problems you've found are submitted to GDB's bug 
> tracking database with proper testcases so that we can track and 
> prioritize the problems efficiently. (Oooooh, that's a management word, 
> isn't it? My bad. O:-)
> 

We'll get on that probably next week.


Last question, is the var-object code in gdb/mi, thread aware?
Anything we should be aware of? Documentation is parse 8).
We decide to give the VarObject a go instead of the usual stack-list-locals 1.
-var-update at every step 8-)


> We'll make it usable yet!


Thanks for the feedback.