This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Accessing struct fields without casting


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]