> Am 07.10.2025 um 18:41 schrieb Tamar Christina <[email protected]>:
>
>
>>
>> -----Original Message-----
>> From: Richard Biener <[email protected]>
>> Sent: 07 October 2025 17:01
>> To: Yury Khrustalev <[email protected]>
>> Cc: Jakub Jelinek <[email protected]>; Jason Merrill <[email protected]>;
>> Mark Wielaard <[email protected]>; [email protected]; Tamar
>> Christina <[email protected]>; Srinath Parvathaneni
>> <[email protected]>; Tejas Belagod <[email protected]>
>> Subject: Re: [PATCH] dwarf: Save bit stride information array type entry
>> [PR121964]
>>
>>
>>
>>> Am 07.10.2025 um 16:54 schrieb Yury Khrustalev
>> <[email protected]>:
>>>
>>> Hi Jakub,
>>>
>>> Thanks for a very detailed response!
>>>
>>>> On Mon, Oct 06, 2025 at 02:24:08PM +0200, Jakub Jelinek wrote:
>>>>> On Wed, Sep 17, 2025 at 04:39:12PM +0100, Yury Khrustalev wrote:
>>>>> Lack of DW_AT_bit_stride in a DW_TAG_array_type entry causes GDB to
>> infer
>>>>> incorrect element size for vector types. The causes incorrect display of
>>>>> SVE predicate variables as well as out of bounds memory access when
>> reading
>>>>> contents of SVE predicates from memory in GDB.
>>>>> ...
>>>> Some nits in the ChangeLog entry, there should be no newline after
>>>> * dwarf2out.cc
>>>> line unless the filename + name of the function is too long to fit
>>>> on one line (not the case here). Plus, both add should be Add
>>>> because after : it starts a sentence.
>>>
>>> Will fix, thanks!
>>>
>>>>> ...
>>>>> + if (TREE_CODE (type) == BITINT_TYPE
>>>>> + || TREE_CODE (type) == BOOLEAN_TYPE)
>>>>> add_AT_unsigned (base_type_result, DW_AT_bit_size, TYPE_PRECISION
>> (type));
>>>>
>>>> This looks wrong to me (and after all, is probably wrong also for
>>>> BITINT_TYPE, but it isn't clear to me how else to represent the _BitInt
>>>> precision in the debug info other than having to parse the name of the
>> type).
>>>> So perhaps something we should discuss in the DWARF committee.
>>>> DWARF5 seems to say that DIEs have either DW_AT_byte_size or
>> DW_AT_bit_size,
>>>> one being in bytes, one being in bits. For _BitInt it is always a type
>>>> with size in bytes but it is interesting to know for how many bits it has
>>>> been declared. For bool/_Bool that number would be 1 and I guess all
>>>> debuggers ought to be handling that fine already without being told.
>>>> I'd certainly not change this for bool/_Bool at this point.
>>>
>>> Noted. I agree that this change would be unnecessary for the issue that I
>>> am trying to solve.
>>>
>>>>> ...
>>>>> + if (TREE_CODE (element_type) == BITINT_TYPE
>>>>> + || TREE_CODE (element_type) == BOOLEAN_TYPE)
>>>>> + add_AT_unsigned (array_die,
>>>>> + DW_AT_bit_stride, TYPE_PRECISION (element_type));
>>>>
>>>> This looks also wrong and actually much worse.
>>>> ...
>>>
>>> Correct, thanks for pointing this out, I entirely missed this.
>>>
>>>> ...
>>>> Unless boolean vectors on non-aarch64/arm/riscv targets can make it,
>>>> I'd suggest to try to handle only
>>>> VECTOR_BOOLEAN_TYPE_P (type)
>>>> && GET_MODE_CLASS (TYPE_MODE (type)) == MODE_VECTOR_BOOL
>>>
>>> This makes sense and works for SVE predicate vectors with one caveat...
>>>
>>>> types and in that case figure out the right stride (1, 2, 4, 8, ...)
>>>
>>>
>>> would imply that TYPE_PRECISION (element_type) is always 1? In this case
>>> we can probably use this:
>>>
>>> VECTOR_BOOLEAN_TYPE_P (type) && TYPE_PRECISION (element_type) == 1
>>
>> IIRC this doesn’t work for SVE.
>
> For a type registered with SVE enabled I think it would work because the
> associated
> mode is BImode then and the precision of BImode is always 1, so I'd expect
> the precision of the type to be too.. but I don't know what happens in the
> case outline
> above where SVE is not enabled at the time of DWARF output. e.g. you get
> BLKmode.
>
>>
>>> and set DW_AT_bit_stride to 1?
>
> I do wonder about this one as well. As Jakub mentioned above you have the
> partial SVE
> modes and if
>
>> But, as even showed in examples in DWARF5, DW_AT_bit_stride is meant for
>> say Pascal PACKED ARRAY (see D.2.7), I think Ada has similar things.
>
> So bit_stride is meant for packed arrays, but the partial modes are unpacked.
>
>> documentation applies. That isn't always 1-bit stride, guess sometimes
>> can be more than 1, e.g. 2 or 4, even on aarch64. What strides do
>> config/aarch64/aarch64-modes.def:VECTOR_BOOL_MODE (VNx8BI, 8, BI, 2);
>> config/aarch64/aarch64-modes.def:VECTOR_BOOL_MODE (VNx4BI, 4, BI, 2);
>> config/aarch64/aarch64-modes.def:VECTOR_BOOL_MODE (VNx2BI, 2, BI, 2);
>> modes have? Isn't that 2, 4 and 8?
>
> Yeah, I think that's right looking at bit positions, so VNx8BI every bit
> controls 2 bytes
> in the datavector, and the only relevant bit is every 2 strides.
>
> So the representation is [0,x,1,x,2,x,3,x,4,...]
>
> As such I think bitstride 1 is wrong and only applicable for fully packed
> vectors.
>
> The difficulty from my understanding is due to mode switching in that unless
> SVE
> was enabled globally, at the time we try to write out the DWARF information
> SVE
> may have been disabled again.
>
> The backend has a method for temporarily re-enabling a target ISA to
> manipulate
> its modes.
>
> Is it possible to call aarch64_target_switcher somehow before dumping the
> DWARF
> output? If so I *think* this might solve the classification issue.
>
> Did I miss anything @Kyrylo Tkachov?
In general we should produce DWARF based on the type, not the mode. It’s
supposed to map to the source, not the target. The layout of a svebool is the
same with or without SVE enabled, no?
>
> Thanks,
> Tamar
>
>>>
>>> The issue with GET_MODE_CLASS (TYPE_MODE (type)) is that TYPE_MODE
>> (type)
>>> may return E_BLKmode because TYPE_MODE would adapt to the current
>> ISA.
>>> In the case of SVE, one can use the svbool_t type with the -march=...+sve
>>> command line flag (in which case TYPE_MODE (type) would work), but it
>>> can also be used with the gnu::target attribute (in which case TYPE_MODE
>> (type)
>>> would return E_BLKmode and the check for MODE_VECTOR_BOOL would
>> fail).
>>>
>>> I appreciate that this seems like a partial solution, but at least it is
>>> correct in a sense that all boolean vectors with element size 1 bit
>>> should have DW_AT_bit_stride = 1.
>>>
>>> Thanks,
>>> Yury
>>>
