This is the mail archive of the gdb-patches@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: [PATCH] Do not consider reference types as dynamic


On 04/17/2015 01:20 PM, Pierre-Marie de Rodat wrote:
This patch causes a regression in gdb.cp/vla-cxx.exp unfortunately,

  print vlaref^M
  $2 = (int (&)[variable length]) @0x3fffffffe900: {5, 7, 9}^M
  (gdb) FAIL: gdb.cp/vla-cxx.exp: print vlaref

which is shown by buildbot
https://sourceware.org/ml/gdb-testers/2015-q2/msg00360.html

This is tough!

For the record, I did not notice this regression because I ran the testsuite with GCC's development branch, and this testcase was already failing with it. It works with GCC 4.9.2, though.

So my understanding was that types are dynamic when we need runtime information to decode them properly (memory layout, range bounds, etc). With this definition, reference types are never dynamic since they are actually mere pointers (static size, no dynamic semantics).

Printing a reference value is supposed to automatically fetch and print the referenced object... and its type. This testcase also tells us that it's the "fully resolved type" that must be printed (I mean referenced types must be resolved, too).

Here, we have "vlaref": a reference to a VLA (variable-length array), hence a reference to a dynamic type (the bounds and thus the size of the array are dynamic). Because of the "dynamic type" definition above, the referenced type is kept as-is during evaluation. And then at type-printing time, we use the dynamic referenced type, hence the "variable length" in the output.

If the definition above is correct, then we should enhance typeprint.c/c-typeprint.c/etc. to resolve dynamic type as type printing goes in order to get the actual array bounds in the output. This means: propagating a (possibly null) value in a lot of functions and use it for type resolution when possible. I guess this would involve a big patch but would also cover the "ptype" case.

I guess another way to "just get things working" would be to revert my previous patch and to enhance the dynamic property mechanism (dwarf2loc.h) to handle reference values that are not present in memory. For instance: extend the property_addr_info structure to hold either the address of objects (as today) or the address of the referenced object (for reference types).

Thoughts?

--
Pierre-Marie de Rodat


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