From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3576 invoked by alias); 24 Mar 2006 20:21:05 -0000 Received: (qmail 3527 invoked by uid 22791); 24 Mar 2006 20:21:01 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 24 Mar 2006 20:20:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FMsmG-00077W-Vu for gdb-patches@sourceware.org; Fri, 24 Mar 2006 15:20:57 -0500 Date: Fri, 24 Mar 2006 21:02:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: MI: type prefixes for values Message-ID: <20060324202056.GA26748@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <17427.54333.236860.258115@kahikatea.snap.net.nz> <20060317191207.GA19068@nevyn.them.org> <20060324030332.GB2853@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00273.txt.bz2 On Fri, Mar 24, 2006 at 11:30:54AM +0300, Vladimir Prus wrote: > > Looking at Eclipse: > > cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java > > > > // Coming from a reference > > if (valueString.startsWith("@")) { //$NON-NLS-1$ > > valueString = valueString.substring(1); > > int colon = valueString.indexOf(':'); > > if (colon != -1) { > > valueString = valueString.substring(colon > > + 1); > > } > > So, Eclipse is manually parsing the "value" string? I pretty sure I've heard > either Bob, or Eli say this is not good idea. In fact, I suspect I heard > both of them say this. Heck, I've said it too. However, in the real world, we need to be a bit careful of frontends which do it. I strongly discourage new frontends doing so, but I also try not to break existing frontends which do - this is an extension of "be liberal in what you accept, but conservative in what you generate". > > } else { > > > > It wants to show the value in its variables window, not the reference. > > So this patch would break it. > > > > So, should we change common_val_print, do you think? > > Short-term, this might be a solution. But note again that depending on > textual "value" field is bad idea in any case. That's not actually what I meant - I'm not thinking of MI here. common_val_print gets called from a number of places: - varobj c_value_of_variable, used by Insight and MI (-var-list-children, -var-evaluate-expression, -var-assign, -var-update). - print_frame_args, where it is used to deliberately print only the address of a reference. I'm not entirely sure why. - Languages, to implement value_print - not relevant right now. > Long-term the right solution is: > > - Port the Apple change that allows to get variable objects for all > local variables in one command. This sounds sensible. > - Port Apple change that add 'typecode' field to variable objects I understand why they did this, but should we really be exposing GDB's internal type system this way? I'd want to see what it gets used for, and probably define it independently of the existing type codes. > - Add command/variable object format to deference references > - Teach Eclipse that for variable object with "reference" typecode, > it should dereference variable object, or whatever is appropriate. > > This could be a long process, though. Yes indeed. Hmm. -- Daniel Jacobowitz CodeSourcery