From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27969 invoked by alias); 3 Mar 2014 21:54:24 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27956 invoked by uid 89); 3 Mar 2014 21:54:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ea0-f171.google.com Received: from mail-ea0-f171.google.com (HELO mail-ea0-f171.google.com) (209.85.215.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 03 Mar 2014 21:54:22 +0000 Received: by mail-ea0-f171.google.com with SMTP id n15so3300635ead.2 for ; Mon, 03 Mar 2014 13:54:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c0jM6SYyXqq/wmnETPWzLVljLH12JCTLLOSBcI+lsh8=; b=begYAMoeQnMNc9u2MMFSwX1JDIubwiGy03XmC0lnBjKZsRnJNg2S1r7Dl3F1/hRzAE 0mA3+ZCeKPrpG0BmPTT7hzImF5YguhaQzDZ34cB3d00H9bpRs6IWYvL9Xmcuaao8K+cN Rv8FuUcq2PRjL2ZNaH917cQGOtArJ0uGPAidatAvzaTy61dqwwY0SQY9naH+wVg3WH5t Z98IghJcSdgQ+eDArxoLlGVKOYVL9TMbToErce1IWwcFt0sKeK8J7rF5wza4J0W9JajZ 5nd5AahHjcx/RF2CjAawSBJQdHMCD3aMhR6sotAL4DxLpULIZo3viMxGf706f6TojQnH f/dg== X-Gm-Message-State: ALoCoQngP2yDcDso7MXA7cxvS6L7/c2KizQzA49YbK+taUqLITYDLNBZHehTDErqaLWkHPrB9pX9n4902v0r8feblpMrXkwh+YwTIV9ktZGCH4fzNNO7seFjHT+aHgl2cslK4IxzCpLddfIMiWi0RdH8o450JlP6YILntgH/pHGXgx3KnxQQpLUXJ92+fhw2Doxtwsm0kJw1 MIME-Version: 1.0 X-Received: by 10.14.220.193 with SMTP id o41mr42590077eep.22.1393883658910; Mon, 03 Mar 2014 13:54:18 -0800 (PST) Received: by 10.15.48.197 with HTTP; Mon, 3 Mar 2014 13:54:18 -0800 (PST) In-Reply-To: References: <5310C3FC.6000006@elis.ugent.be> Date: Mon, 03 Mar 2014 21:54:00 -0000 Message-ID: Subject: Re: Accessing struct fields without casting From: Siva Chandra To: Doug Evans Cc: Tim Besard , gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00004.txt.bz2 On Sat, Mar 1, 2014 at 12:36 PM, Doug Evans wrote: > On Fri, Feb 28, 2014 at 9:14 AM, Tim Besard wrote: >> Hi list, >> >> I'm working with some code base which expresses most internally >> used values in terms of some struct "value_t" only containing a single >> field, "kind". This field is used as an discriminator, and based on its >> value the object is cast after which its available fields can be >> accessed (see attached test case). >> >> Since this is pretty hard to work with from within GDB, especially >> because the "kind" field doesn't contain human readable text but rather >> raw memory (a pointer to a globally defined object), I wrote a pretty >> printer which detects the actual type of "value_t" objects, casts them, >> and displays the actual typename when called with to_string() and >> returns the casted value its fields when called with children(). >> >> However, this doesn't ease debugging much, because despite implementing >> a children() method which lists all available fields GDB doesn't allow >> to access those without an explicit cast (see attached sample). >>> (gdb) print value->foo >>> There is no member named foo. >>> (gdb) print ((example_t*)value)->foo >>> $1 = 42 >> This is even worse in the actual code, where value_t "subtypes" often >> contain pointers to other value_t "subtypes", but since those pointers >> are always of type "value_t*" I need to pretty print them in order to >> know the type and then cast them in before I can finally access its fields. >> >> Is it possible to teach GDB about the "actual" type of these objects, or >> work around this problem in some other way so that I can access subtype >> fields without having to cast each object manually? > > Hmmm, Siva's original "debug methods" patch would let you handle this > nicely (I think). > It let one hook python implementations into the expression parser. > > Seems like we can make good use of *both* flavors (one that hooks into > the parser, and one that hooks into method lookup). My patch from back then focused on the operators and not the on the operands. Looking at the OP's example, it seems to me that we should focus on the operand. So, a possible feature that comes to my mind is a "dynamic incarnation" facilitated via an extension language. For example, when GDB sees a particular value of type Foo in an expression, it can call into the extension languages to check if they want this value to be incarnated into a value of type Bar. This incarnation could be achieved by something like a cast operation for example (which is what the OP's requirement is). In general, how a value of type Bar is derived from the value of type Foo is upto what the user wants and need not always be a cast. [That is the reason I call it a "dynamic incarnation" operation, and not a "dynamic cast" operation, as it need not be like the C++ dynamic_cast in general. But, I am not sure if we should support more than casting at all.] Thanks, Siva Chandra