DW_OP_deref_type and vector registers

[woodard]

Beginning in line 513 in 0001 when defining DW_OP_deref_type

The DWARF is ill-formed if D is not in the current compilation unit,
D is not a DW_TAG_base_type debugging information entry, or if TS
divided by 8 (the byte size) and rounded up to a whole number is not
equal to S.

What if you call DW_OP_deref_type on a vector register? In that case D will not be a DW_TAG_base_type it would be an array of the base types.

[t-tye]

The DW_OP_deref* operations are only defined to act on a single address. If a vector register held a number of addresses, then a location description would need to be created for the part of the vector register that had the address that wanted to be dereferenced. For example, the DW_OP_lane could be used to select the part of the vector register that corresponded to the currently selected lane. That location description would then be treated as an address base type.

[woodard]

I'm not arguing that the address (or addresses) that is popped off the stack would need to be a vector of addresses. I'm suggesting that the type pointed at by the type need not exclusively be a DW_TAG_base_type, it could also be a vector register type which in theory could be a base type for the architecture but for historical reasons is a n array type of base types. I see that this carries over from the current DWARF5 standard in 2.5.1.3 #8 but I believe that is wrong in light of how vector registers are defined.

I thought that I had put in an issue to standardize GNU_vector (which should have been standardized in DWARF4 IIRC but it was overlooked) but I don't see it in the list of issues.

[ 7c] base_type abbrev: 3
byte_size (data1) 4
encoding (data1) float (4)
name (strp) "float"
...
[ 7b5] typedef abbrev: 8
name (strp) "__m128"
decl_file (data1) xmmintrin.h (7)
decl_line (data1) 69
decl_column (data1) 15
type (ref4) [ 7c1]
[ 7c1] array_type abbrev: 30
GNU_vector (flag_present) yes
type (ref4) [ 7c]
sibling (ref4) [ 7cd]
[ 7ca] subrange_type abbrev: 31
upper_bound (data1) 3

What do we want to do here? Should we split out yet another issue which standardized GNU_vector and also loosens the requirement that the type be a base type or should we fold it into this proposal which also update that same piece of text. The problem is that the changes collide.

[t-tye]

If there was a vector register that held a number of addresses, then the computed location description would be only for a single address, not a vector of addresses. Location descriptions on the stack do not have types in this proposal. When the location description is de-referenced it would produce a value that has a base type that matches the single address integral type.

The full proposal does include an item to add support for vector types as base types. See:

• https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#support-for-vector-base-types
• https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#a-5-1-base-type-entries

I am not sure how that compares with the GNU proposal.

[woodard]

I just created a pull request to codify the way that GNU and LLVM currently handle vector registers.

[woodard]

#18 the basic idea is they do not consider vector registers base types. They consider them to be array types with a special flag which indicates that they are vectors. I had thought that I had written up this proposal a long time ago but I can't find it and Jason has no record of it.

However, this discussion has been helpful because almost all of my work has been with ABI and I hadn't looked into expressions as deeply as have had to with this and so if and when I originally wrote it up, I think it is likely that I would have missed the DW_TAG_base_type requirements for certain operators in the expression section.

Since I couldn't find my previous work, I created this file de novo this morning and haven't had a chance to run it past Jason or Jakub yet. I expect that there will need to be some changes. And as I said, if you don't want it to be part of this body of work, that is fine with me. Jason told me to make sure that I get it in the DWARF issue queue.