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

[Keith Seitz <keiths@xxxxxxxxxx>]

On Thu, 22 Aug 2002, Alain Magloire wrote:

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

I do! ;-)

> 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)

This is wrong. Either we need to fix this to conform to the spec, or we 
need to change the spec.
 
>   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.

Anything starting with a "~" is meant to go unprocessed directly to 
something like a GDB console. It is not meant for MI clients to parse.
There is a new event which should communicate thread switches in the 
pipeline.

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

When in doubt, check src/gdb/mi/mi-cmds.c. There's a big table of all the 
supported commands. (I think that the MI manual is also kept quite up to 
date and brutally honest, too, at 
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC212 )

> -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?

It will be gone when I complete my checkins. I think it is best to deal 
only with event processing for things like this. This is how we have done 
it in Insight for a few years now, it is MUCH more reliable than trying to 
figure everything out:

(gdb)
-break-insert main
=breakpoint-create,number="1"
(gdb)
-break-info 1
^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08074fc6",func="main",file="../../src/gdb/main.c",line="743",times="0"}]}

This way, you only have to be able to parse "break-info", and you'll never 
have stray breakpoints because the GUI thought it successfully set a 
breakpoint but GDB didn't insert it for some (often times obscure) reason.

> 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.

Yich.  I haven't played with threads too much yet under MI (I usually 
debug GDB on itself). But I'll make sure I play with it before we're 
through. If you ever find any bugs or have questions, don't hesitate to 
ask on the mailing list or submit a bug.

> 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-)

Varobj should be safe to use in a threaded environment. Each varobj knows 
to what frame it belongs, so it naturally is tied to a specific thread.

Keith