Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] debug gdb/mi updates

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!

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

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

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

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

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

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

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

> 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 make it usable yet!
Keith




Back to the top