Re: [cdt-debug-dev] MI questions

["Alain Magloire" <alain@xxxxxxx>]

> 
> On Fri, 27 Sep 2002, Alain Magloire wrote:
> 
> > Keith Seitz wrote:
> > >
> > > I've finally given up on getting my interpreter stuff into GDB. So in the 
> > 
> > interpreter? tell me more about it.
> > one of the long term project of the CDT debugger is to come with something
> > like UPS, which comes with some ANSI C interpreter.  Eclipse/JDT as there
> > own interpreter to evaluate complex expressions.
> 
> This intepreter stuff will allow MI clients access to GDB's command line 
> interpreter. So you can have something for users to type at (like 
> Insight's Console Window).

Excellent!  To provide console prompt to let (experience)users drive the
debugger is something on the TODO list.  But for this gdb/MI has to
return __MI responses__  not merely streams response.  If not the UI
can not be updated and will fall out of sync.

BTW, can gdb/mi deals with .gdbinit?

> 
> Gdb has a built-in language-specific interpreter. It's not literal, but it 
> is very, very close. I think that if you have an arbitrary expression, you 
> can use the "-data-evaluate-expression" command to get GDB to evaluate 
> (while GDB is running, of course). Probably not entirely what you were 
> after...

Close enough, but this is for the future, and hopefully 5.4 and above
will correct problems like this:

-data-evaluate-expression printf("hello world")
^error,msg="mi_cmd_data_evaluate_expression: Usage: -data-evaluate-expression expression"

We've exchange about this in another thread.

> (gdb)
> -environment-directory /home/keiths:/home/keiths/tmp/"this"
> ^done
> (gdb)
> -gdb-show dir
> ~"Source directories searched: /home/keiths:/home/keiths/tmp/\"this\":$cdir:$cwd\n"
> ^done
> 
> Looks like clearing it doesn't work, either. Sigh. I'll fix this for you. 
> I'll create a bug for all of these path problems (and CC you).

Thanks.

> 
> > * -break-list
> >    - doing break-list will also send the BreakpointTable
> >    is it possible to not to, in UI environment the table is useless
> >    how about: 
> >     -break-list 1
> >     ^done body=[bkpt=....
> >   only the bodies.
> 
> I don't think there is much choice here right now, and I don't forsee GDB 
> maintainers changing this. This is simply how MI operates. The CDT MI
> parser should be able to parse the table and extract the relevant info.

Done.

> 
> > * -environment-directory
> >    How to reset/clear the list?
> >    in CLI gdb one can do "dir" with no arguments
> > 
> >    How to get back the list? One could do
> >    -gdb-show directories
> >    ~"Source directories searched: $cdir:$cwd\n"
> >    ^done
> >    But not properly MI wrap, the strange thing it seems to
> >    work for some other variables(proper MI wraps)
> >    -gdb-show annotate
> >    ^done,value="0"
> > 
> >    the MIResult "value" is used to return the answer.
> 
> I'll add all this to the PR.
> 

Thanks.

> > * -environment-path
> >   Same has "-environment-directory"
> >   How to get the value?
> >   if the answer is:
> >   -gdb-show path
> >   ~"Executable and object file path: /usr/sbin:/sbin:/usr/local/gdb/bin:/usr/local/jdk/bin:/export/WebSphere/eclipse:/usr/sbin:/sbin:/usr/local/gdb/bin:/usr/local/jdk/bin:/export/WebSphere/eclipse:/usr/sbin:/sbin:/usr/local/gdb/bin:/usr/local/jdk/bin:/export/WebSphere/eclipse:/usr/sbin:/sbin:/usr/local/gdb/bin:/usr/local/jdk/bin:/export/WebSphere/eclipse:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/alain/bin:/home/alain/bin\n"
> >   ^done
> > 
> >    This not proper MI syntax, in the sense, that we have to do some addhoc
> >    parsing, how about:
> >   -gdb-show path
> >   ^done value=[{/usr/sbin},{/sbin},...}]
> >   ^done
> 
> This sounds reasonable. I'll file a PR.

Cool, thanks.

> > * -environment-pwd
> >   Same remarks has above:
> >   -environment-pwd
> >   ~"Working directory /home/alain.\n"
> >   ^done
> > 
> >   Should be a proper MI format
> >   ex:
> >    -environment-pwd
> >    ^done value="/home/alain"
> 
> I'll file a PR.
> 

Saw it, thanks.

> > * Variable notification
> >   - assignment: Doing a -var-assign follow by a
> >     -var-update does not show any variables been change.
> >     Is this the behaviour?
> 
> Yes. (Didn't I get back to you on this already? I thought I had.) Any, the 
> way varobj works, it saves a copy of GDB's internal representation for a 
> variable. When one updates the root (-var-update), it computes a new 
> "value" and compares against the old one.
> 

Ok, we can deal with this, by firing the events ourselves.

> When you assign a new value to a variable (and it succeeds), this new 
> "value" is saved and used for subsequent comparisons (of whether anything 
> has changed). This contrasts to how registers work, but the register stuff 
> is wrong, IMO. :-) (This happens because MI doesn't modify its "value" for 
> the register like varobj does.)
> 

Are you refering to the -data-list-registers-xxxx commands or
to using the use of registers as variable objects?
The use of registers as variable object made things more easier
especially when dealing with complex registers like xmm[0-7]
But we are reverting to -data-list-register-xx see other post.

> >   - And on a more complex note, doing -data-write-memory
> >     to some memory and the memory was a variable object
> >     should -var-update notice this?
> 
> Yes. In HEAD sources it certainly does. [Aside: In mi2, this will trigger
> an event telling you that something has changed. Unfortunately, we cannot 
> tell you WHAT changed. Only that the state of the target has changed. This 
> is necessary because there are some really goofy systems out there, like 
> those with memory-mapped registers.]

When you trigger an event, do you mean after an
-var-update *
or after the assignment or a changelist={...} will magically appear
from a oob.

> 
> > * Variable Objects and Registers.

See other post.

> 
> >     Now, we are doing the following modification:
> >     - issue "-var-update *" once when the inferior is stopped
> >     - use the "-data-xxx-registers-xxx" calls to deal with registers
> >       instead of var-objects.
> >     We seem to get a better stability of the debugger(gdb).
> 
> In insight, we use the equivalent of data-list-* for all register displays 
> (except if a user enters a register as a watch expression).
> 

Good advice, I'll take it 8-)

> > * -thread-list
> >    corrected(from your patch), but we still use "info threads" since
> >    we have to assume that the gdb version is 5.2.1(mi1)
> 
> Ok. (BTW, I did not commit the list change, as you suggest.)
> 

Thanks!