Accessing struct fields without casting

Accessing struct fields without casting

[Tim Besard]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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?

Thanks,
-- 
Tim Besard
Computer Systems Lab
Department of Electronics & Information Systems
Ghent University


[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 523 bytes --]

#include <stdio.h>
#include <stdlib.h>

#define KIND int kind;
#define example_kind 1

typedef struct {
  KIND
} value_t;

typedef struct {
  KIND
  int foo;
} example_t;

int main() {
  value_t *value = (value_t *)malloc(sizeof(example_t));
  ((example_t *)value)->kind = example_kind;
  ((example_t *)value)->foo = 42;

  switch (value->kind) {
  case example_kind:
    printf("example_t with foo=%d\n",
           ((example_t *)value)->foo);
    break;
  default:
    printf("unknown value kind\n");
  }

  return 0;
}

Re: Accessing struct fields without casting

[Doug Evans]

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).

Re: Accessing struct fields without casting

[Siva Chandra]

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