> -----Original Message-----
> From: Richard Biener <[email protected]>
> Sent: 07 October 2025 18:16
> To: Tamar Christina <[email protected]>
> Cc: Yury Khrustalev <[email protected]>; Kyrylo Tkachov
> <[email protected]>; Jakub Jelinek <[email protected]>; Jason Merrill
> <[email protected]>; Mark Wielaard <[email protected]>; gcc-
> [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 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?
You're right, the svbool_t specifically is always registered with VNx16BI, so
It'll always be single bit precision. So in that regard Yury's patch is
correct if we
only ever put out DWARF for svbool_t.
I however don't know what the expected experience here is.
Consider:
#include <arm_sve.h>
svbool_t f8 ()
{
return svptrue_b8 ();
}
svbool_t f16 ()
{
return svptrue_b16 ();
}
The first one has every bit significant, and the second one it's every 2nd bit.
But with DW_AT_bit_stride = 1, I'm not sure how a user in GDB is able to tell
If the register values belong to a predicate where every other lane is inactive
or one where every entry is active.
But as Yury mentioned at the very least DW_AT_bit_stride = 1 would fix the
output corruption in gdb.
Thanks,
Tamar
>
> >
> > 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
> >>>
