This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: plan: VLA (Variable Length Arrays) and Fortran dynamic types
On Thu, 29 Nov 2012 22:51:07 +0100, Tom Tromey wrote:
> Passing a struct value everywhere seems pretty awful though too,
> especially considering that one may not generally have a value.
> 'ptype' and plenty of other things have to work on the abstract type.
There is needed 'struct value' with some dummy content in such case.
It also means you cannot 'ptype' VLA type (or dynamic Fortran array), you need
an inferior variable instance for VLA.
I have checked now that 'ptype char[5]' works even without VLA. But that sets
TYPE_LENGTH to 5 and TYPE_TARGET_STUB == 0 so check_typedef does not overwrite
the value 5 (it also has no TYPE_CODE_RANGE anywhere).
Dummy 'struct value' is the disadvantage of a fully dynamic solution but it is
nice we share the opinion with Joel a fully dynamic solution (without
concretization) should be better.
I did not use you words 'abstract type' as I used 'struct abstract_type' in my
text also for inferior types not yet passed through check_typedef.
For non-VLA types it means 'struct abstract_type' may be opaque type.
> But I think maybe I don't understand some details here. Could you give
> an example of where we pass a type now that we would have to pass a
> value in the future?
It may also depend a bit on the behavior currently in archer-jankratochvil-vla
as:
(gdb) whatis temp1
type = char [variable]
(gdb) ptype temp1
type = char [78]
Currently it did mean how many check_typedefs to call, with fully dynamic
types in GDB there will need to be different way (flag) to access the array
bound value.
For example LA_PRINT_TYPE parameter type -> value. I do not know more, just
change type->value at any TYPE_LENGTH and similar accessors, and then change
it in all the callers.
Jan