From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32564 invoked by alias); 25 Sep 2008 04:33:26 -0000 Received: (qmail 32553 invoked by uid 22791); 25 Sep 2008 04:33:26 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 Sep 2008 04:32:47 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KiiWx-0001eb-OQ for gdb-patches@sources.redhat.com; Thu, 25 Sep 2008 04:32:44 +0000 Received: from 201.82.215.197 ([201.82.215.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2008 04:32:43 +0000 Received: from bauerman by 201.82.215.197 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2008 04:32:43 +0000 To: gdb-patches@sources.redhat.com From: Thiago Jung Bauermann Subject: Re: [rfc] expose gdb values to python Date: Thu, 25 Sep 2008 04:33:00 -0000 Message-ID: References: <1221199426.24580.26.camel@localhost.localdomain> <20080921042657.GB29631@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00496.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Sep 19, 2008 at 04:39:12PM -0600, Tom Tromey wrote: >> Thiago> I believe it's better to avoid using current_language, right? >> Thiago> I don't think there's a way to get a sensible language_defn to >> Thiago> use here, so my only idea is to add an element to struct value >> Thiago> which holds the language associated with the value. This >> Thiago> element would be filled at the moment the value is created. >> >> My first reaction to this was "no way". Well, thanks for the sincerity I suppose. :-) >> But, I couldn't think of a >> concrete case where this would have bad results -- especially provided >> we restrict use of the language field to stringifying the value. > > This seems iffy. A value's just a value - how it's printed depends on > how it's used, not how it was created. e.g. if two languages had > different number formatting, "print $1" should generate different > results based on the current language. > > So what the right language is may depend on the context. My reasoning was that if a value comes from a C context (for example), at least at first I'd expect it to always be printed in C syntax. But I see your point. And I have no preference, really. So leaving current_language in valpy_str is acceptable? Then one FIXME can be just dropped. >> There are some intermediate ideas, too, like allowing the invisible >> approach only when the field name is unique; or we could define the >> search order. (It is tempting to use the language's rules, but I >> suspect this might be too tricky to get right.) > > Why isn't this the same as for expression evaluation in GDB today? > That does follow the language rules (and fail, in some cases). >From what I understood of the expression evaluator, this means just calling value_struct_elt to find the element. If that's the case, it's what this patch implements. Is it useful to provide a casting mechanism, to enable for instance access to elements from a specific type in the inheritance hierarchy? With that, a python script will have the same capability as the user at the GDB prompt to access any struct/class element, right? But I'd leave type casting to the (still to be written) patch exposing the type system to python. > I'm not sure we really need length to work, but I haven't spent much > time looking at it. If we don't, I'd rather it failed always than > intermittently. A function which always fails? I can write that. :-) -- []'s Thiago Jung Bauermann IBM Linux Technology Center