Re: [PATCH] Do not consider reference types as dynamic

[Pierre-Marie de Rodat <derodat@adacore.com>]

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