Re: Accessing struct fields without casting

[Siva Chandra <sivachandra at google dot com>]

On Sat, Mar 1, 2014 at 12:36 PM, Doug Evans <dje@google.com> wrote:
> On Fri, Feb 28, 2014 at 9:14 AM, Tim Besard <tim.besard@elis.ugent.be> 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