> 1$: DW_TAG_structure_type
> DW_AT_name("Record_Type")
>
> 2$: DW_TAG_member
> DW_AT_name("N")
> DW_AT_type(reference to Integer)
>
> 3$: DW_TAG_array_type
> DW_AT_type(reference to Integer)
>
> 4$: DW_TAG_subrange_type
> DW_AT_type(reference to Integer)
> DW_AT_lower_bound(constant 1)
> DW_AT_upper_bound(reference to member N at 2$)
>
> 5$: DW_TAG_member
> DW_AT_name("A")
> DW_AT_type(reference to array type at 4$)
>
> With this debug info, the upper bound of "A" indeed completely mirrors
> the value of "N". In GCC, however, computing the upper bound of "A" is
> more subtle: it is internally represented as: max(0, <record>.N) so that
> when "N" is negative, 0 is returned.
>
I`m not being familiar with internal gcc representations but what is
preventing you of referencing the member N? In our gdb-vla branch
at [1] we have added support for such indirection as it is emitted by
icc for c99 vla. Looking at the example above we might need to extend the
indirection to cover references to members as well as they do not have
a DW_AT_location.
> # Push N, then 0
> ??? Get the value of the "N" member;
> DW_OP_lit0;
>
> # Is N > 0?
> DW_OP_over; DW_OP_over;
> DW_OP_gt;
> DW_OP_bra: 1;
>
> # If not then return 0, else return N.
> DW_OP_swap
> DW_OP_drop
>
> So the issue for me is to know what to put instead of the "???" part. It
> looks like the DW_OP_push_object_address (defined in section 2.5.1.3
> Stack Operations) was introduced specifically for this kind of
> computation, but I'm not sure what it is supposed to mean in this
> context. Indeed, this operation would appear as part of a DWARF
> expression under a DW_TAG_subrange_type DIE, itself under a
> DW_TAG_array_type DIE, itself under a DW_TAG_structure_type. So what
> address would this operation push on top of the stack? The address of
> the "A" member, or the address of the embedding record?
>
It pushes the address of the currently evaluated object, in your case
it is the address of member "A".
You may have a look at 'D.2 Aggregate Examples' and Figure 51 in the
latest dwarf standard. DW_OP_push_object_address is usually used to
address meta information of a type e.g. bound information of an array.
This information is usually part of the array descriptor hence the
address of the object is needed and not the embedding type.
> The offsets of discriminants (the special record members that can be
> used to determine the size of regular record members) inside the record
> are statically known, so getting the address of the embedding record
> would be enough to be able to fetch the value of the discriminant.
>
Can you illustrate the record descriptor representation? e.g. a simple
representation in form of a C struct.
My knowledge about how vla work is pretty limited to C99 and Fortran.
It might help to understand the problem a bit better.
> On
> the other hand, getting the address of the "A" member would not be
> sufficient: in more complex cases, the offset of the "A" member can
> depend on discriminants!
>
So the bounds information of an array is not stored as part of the array
descriptor but rather in the embedding type?
> I tried to look at the implementation of DW_OP_push_object_address in
> GDB, but it looks like it's not implemented yet. What do you think about
> its expected behavior?
We have implemented the opcode in our vla project at [1], see commits [2]
and [3].
[1] https://github.com/intel-gdb/vla/commits/vla-fortran
[2]
https://github.com/intel-gdb/vla/commit/2d354ffed66a91a0ecf5848f33179c2b4e84c115
[3]
https://github.com/intel-gdb/vla/commit/014913ff8433a661ee8a1dfe158d66465c8f343c
-Sanimir
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
