MI questions from eclipse.org

[Keith Seitz <keiths at redhat dot com>]

Hi,

For the record: some of the MI issues that the eclipse cdt folk are 
running into. This includes my initial response to them.

Keith
---------- Forwarded message ----------
Date: Fri, 27 Sep 2002 10:00:21 -0700 (PDT)
From: Keith Seitz <keiths@redhat.com>
To: cdt-debug-dev@eclipse.org
Subject: MI questions

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

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

> =================== GDB/MI issues  ======================
> * What's the formal syntax for passing parameters:
>   ex:
>   -environment-directory "/home/alain:/tmp"
>   &"Warning: /home/alain/\"/home/alain: No such file or directory.\n"
>   &"Warning: /tmp\": No such file or directory.\n"
>   ^done
> 
>   If my paths contains spaces or ':'?
>   - quotes
>   - escaping

Ok, this is probably something that needs to be straightened out in MI and 
GDB. Spaces don't seem to work no matter what. Ditto for ":", both of 
which seemed to be reserved for the dir command. (The MI command 
"-environment-directory" just invokes "dir %s". This is probably a large 
part of the problem.)

$ mkdir ~/tmp/\"this\"
$ gdb -nw -nx -q -i mi
(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).

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

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

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

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

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

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

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

> * Variable Objects and Registers.
>   - I'm currently changing the implementation:
>     The current(soon to change) way, was to create variable object
>     for all the registers.  In the UI when different stackframe was
>     selected this would map to:
>     -thread-select 1
>     -stack-select-frame 2
>     -var-update *
>     when the answer of the "-var-update" would be parse to construct
>     events fired to the UI views telling them that some registers changes
>     Problems:  Doing this "-var-update *" make gdb misbehaved and returning
>     errors like
>     -var-update *
>     ~"can not access memory at 0xf4"

How did you create the varobj?

> 
>     and gdb would simply hang.  Or sometimes "-var-update *" would
>     would not answer at all.  We took for granted that "-var-update *"
>     was a "light" call and would issue it 4-5 times.

It should work. Maybe there is an underlying GDB bug? It certainly works 
for me when I tried it on a (non-threaded) app. Got a testcase?

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

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

Keith