Pahole, BTF, and vector types

Pahole, BTF, and vector types

[Bruce McCulloch]

Hello Alan, Arnaldo, All,

Recently the Linux Toolchain team at oracle had reason to start emitting 
types
with the vector_size() attribute as arrays when compiling with 
-gctf/-gbtf. This
is a change from the previous behavior, which was to emit these as unknown
types. This emission as an array is consistent with BTF generated in 
both clang
and pahole. We have some ideas on how to implement the change in GCC, 
but were
wondering if anyone involved with dwarves had any insight into why 
vectors are
emitted in this way. More specifically, there were concerns surrounding the
practical differences between vectors and arrays in the realm of memory 
(e.g.
Vectors can be passed as args by value, while arrays cannot). More 
information
about this can be found on the DWARF std issues list [1].

Any input on this subject would be much appreciated.

Bruce

[1] https://dwarfstd.org/issues/230413.1.html

Re: Pahole, BTF, and vector types

[Alan Maguire]

hi Bruce

On 13/05/2025 23:39, Bruce McCulloch wrote:
> Hello Alan, Arnaldo, All,
> 
> Recently the Linux Toolchain team at oracle had reason to start emitting
> types
> with the vector_size() attribute as arrays when compiling with -gctf/-
> gbtf. This
> is a change from the previous behavior, which was to emit these as unknown
> types. This emission as an array is consistent with BTF generated in
> both clang
> and pahole. We have some ideas on how to implement the change in GCC,
> but were
> wondering if anyone involved with dwarves had any insight into why
> vectors are
> emitted in this way. More specifically, there were concerns surrounding the
> practical differences between vectors and arrays in the realm of memory
> (e.g.
> Vectors can be passed as args by value, while arrays cannot). More
> information
> about this can be found on the DWARF std issues list [1].
> 
> Any input on this subject would be much appreciated.
> 
> Bruce
> 
> [1] https://dwarfstd.org/issues/230413.1.html
> 


As far as I can see in dwarf_loader.c we do record that an array type is
a vector, noting that struct array_type specifies true for its
"is_vector" field if the DIE has a DW_AT_GNU_vector attribute, but this
information is not used during BTF encoding; they are as you say just
treated like normal arrays.

So we do have the information available to potentially do something
different for vectors at BTF encoding time. Did you have a specific
representation in mind? Thanks!

Alan

Re: Pahole, BTF, and vector types

[Nick Alcock]

On 14 May 2025, Alan Maguire told this:

> On 13/05/2025 23:39, Bruce McCulloch wrote:
>> Hello Alan, Arnaldo, All,
>> 
>> Recently the Linux Toolchain team at oracle had reason to start emitting
>> types
>> with the vector_size() attribute as arrays when compiling with -gctf/-
>> gbtf. This
>> is a change from the previous behavior, which was to emit these as unknown
>> types. This emission as an array is consistent with BTF generated in
>> both clang
>> and pahole. We have some ideas on how to implement the change in GCC,
>> but were
>> wondering if anyone involved with dwarves had any insight into why
>> vectors are
>> emitted in this way. More specifically, there were concerns surrounding the
>> practical differences between vectors and arrays in the realm of memory
>> (e.g.
>> Vectors can be passed as args by value, while arrays cannot). More
>> information
>> about this can be found on the DWARF std issues list [1].
>> 
>> Any input on this subject would be much appreciated.
>> 
>> Bruce
>> 
>> [1] https://dwarfstd.org/issues/230413.1.html
>> 
>
>
> As far as I can see in dwarf_loader.c we do record that an array type is
> a vector, noting that struct array_type specifies true for its
> "is_vector" field if the DIE has a DW_AT_GNU_vector attribute, but this
> information is not used during BTF encoding; they are as you say just
> treated like normal arrays.
>
> So we do have the information available to potentially do something
> different for vectors at BTF encoding time. Did you have a specific
> representation in mind? Thanks!

We were thinking of simply turning on the kind_flag in the
BTF_KIND_ARRAY for such arrays-that-are-actually-vectors: it's not used
for anything else as yet, and that means we don't need to add something
to the vlen (which would of course be a compatibility break, though BTF
seems to care relatively little about such things). Adding a new meaning
for kind_flag 1 ("is a vector") is relatively compatibility-concern
free.

(I'm assuming that being a vector is a one-bit decision: vectors don't
seem to have any other properties beyond those arrays have in the DWARF
representation nor in GCC nor clang, that I can see.)

-- 
NULL && (void)