From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20194 invoked by alias); 27 Sep 2002 17:58:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20172 invoked from network); 27 Sep 2002 17:58:39 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 27 Sep 2002 17:58:39 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g8RHePi14197 for ; Fri, 27 Sep 2002 13:40:25 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g8RHwcf06886 for ; Fri, 27 Sep 2002 13:58:38 -0400 Received: from valrhona.uglyboxes.com (IDENT:WSp5cXX0SuIY/UqWAfRPvcIlFlbm8+8Z@vpn50-63.rdu.redhat.com [172.16.50.63]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g8RHwbJ00460 for ; Fri, 27 Sep 2002 13:58:37 -0400 Date: Fri, 27 Sep 2002 10:58:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: gdb@sources.redhat.com Subject: MI questions from eclipse.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-09/txt/msg00478.txt.bz2 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 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