Re: [PATCH RFC bpf-next 1/4] bpf: add struct largest member size in func model

[Xu Kuohai <xukuohai@huaweicloud.com>]

On 4/24/2025 9:38 PM, Alexis Lothoré wrote:
> Hi Xu,
> 
> On Thu Apr 24, 2025 at 2:00 PM CEST, Xu Kuohai wrote:
>> On 4/24/2025 3:24 AM, Alexis Lothoré wrote:
>>> Hi Andrii,
>>>
>>> On Wed Apr 23, 2025 at 7:15 PM CEST, Andrii Nakryiko wrote:
>>>> On Thu, Apr 17, 2025 at 12:14 AM Alexis Lothoré
>>>> <alexis.lothore@bootlin.com> wrote:
>>>>>
>>>>> Hi Andrii,
>>>>>
>>>>> On Wed Apr 16, 2025 at 11:24 PM CEST, Andrii Nakryiko wrote:
>>>>>> On Fri, Apr 11, 2025 at 1:32 PM Alexis Lothoré (eBPF Foundation)
>>>>>> <alexis.lothore@bootlin.com> wrote:
> 
> [...]
> 
>>> Thanks for the pointer, I'll take a look at it. The more we discuss this
>>> series, the less member size sounds relevant for what I'm trying to achieve
>>> here.
>>>
>>> Following Xu's comments, I have been thinking about how I could detect the
>>> custom alignments and packing on structures, and I was wondering if I could
>>> somehow benefit from __attribute__ encoding in BTF info ([1]). But
>>> following your hint, I also see some btf_is_struct_packed() in
>>> tools/lib/bpf/btf_dump.c that could help. I'll dig this further and see if
>>> I can manage to make something work with all of this.
>>>
>>
>> With DWARF info, we might not need to detect the structure alignment anymore,
>> since the DW_AT_location attribute tells us where the structure parameter is
>> located on the stack, and DW_AT_byte_size gives us the size of the structure.
> 
> I am not sure to follow you here, because DWARF info is not accessible
> from kernel at runtime, right ? Or are you meaning that we could, at build
> time, enrich the BTF info embedded in the kernel thanks to DWARF info ?
>

Sorry for the confusion.

What I meant is that there are two DWARF attributes, DW_AT_location and
DW_AT_byte_size, which tell us the position and size of function parameters.

For the example earlier:

struct s2 {
       __int128 x;
} __attribute__((aligned(64)));

int f2(__int128 a, __int128 b, __int128 c, int64_t d, __int128 e, int64_t f, struct s2 g)
{
     return 0;
}

On my build host, the DW_AT_location attributes for "e", "f", and "g" are:

<2><ee>: Abbrev Number: 2 (DW_TAG_formal_parameter)
     <ef>   DW_AT_name        : e
     ...
     <f6>   DW_AT_location    : 2 byte block: 91 0       (DW_OP_fbreg: 0)

<2><f9>: Abbrev Number: 2 (DW_TAG_formal_parameter)
     <fa>   DW_AT_name        : f
      ...
     <101>   DW_AT_location    : 2 byte block: 91 10     (DW_OP_fbreg: 16)

<2><104>: Abbrev Number: 2 (DW_TAG_formal_parameter)
     <105>   DW_AT_name        : g
      ...
     <10c>   DW_AT_location    : 2 byte block: 83 0      (DW_OP_breg19 (x19): 0)

We can see "e" and "f" are at fp+0 and fp+16, but "g" is in x19+0. Disassembly shows x19
holds a 64-byte aligned stack address.

For the two questions you mentioned, I’m not sure if we can access DWARF attributes
at runtime. As for adding parameter locations to BTF at building time, I think it
means we would need to record CPU-related register info in BTF, which I don’t think
is a good idea.

> Thanks,
> 
> Alexis
>