poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] pickles: Improvements to btf.pk


From: Jose E. Marchesi
Subject: Re: [PATCH] pickles: Improvements to btf.pk
Date: Tue, 16 Feb 2021 18:08:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> On 2/14/21 9:09 AM, Jose E. Marchesi wrote:
>> 
>>>> +type BTF_Section =
>>>> +  struct
>>>> +  {
>>>> +    BTF_Header header;
>>>> +    BTF_Type[header.type_len] types;
>>>> +    string[header.str_len] strings;
>>>> +
>>>> +    /* Given an offset into the BTF strings section, return the string.  
>>>> */
>>>> +
>>>> +    method get_string = (offset<uint<32>,B> off) string:
>>>> +      {
>>>> +        return string @ strings'offset + off;
>>>> +      }
>>>> +  };
>>>
>>> Now that I think of it, arent the location of `types' and `strings'
>>> determined by the header as an offset relative to the end of the header?
>>> Something like this:
>>>
>>> type BTF_Section =
>>>   struct
>>>   {
>>>     BTF_Header header;
>>>     BTF_Type[header.type_len] types @ header'size + header.type_off;
>>>     string[header.str_len] strings @ header'size + header.str_off;
>>>     ...
>>>   };
>>>
>>> Or, alternatively, this may be more clear but less compact:
>>>
>>> type BTF_Section =
>>>   struct
>>>   {
>>>     BTF_Header header;
>>>
>>>     var type_off = OFFSET + header.type_off;
>>>     var str_off = OFFSET + header.str_off;
>>>
>>>     BTF_Type[header.type_len] types @ type_off;
>>>     string[header.str_len] strings @ str_off;
>>>     ...
>>>   };
>>>
>>> Note how in a struct type definition OFFSET always holds the offset of
>>> the end of the last mapped field, relative to the beginning of the
>>> struct.
>> 
>> And, if we do like above, we don't need the `btf_types' and
>> `btf_strings' functions anymore.  Just accessing section.types and
>> section.strings would be enough.
>> 
>
> Ahh, thank you for pointing this out! I was not aware of the OFFSET
> syntax for specifying things like this. I will fix this soon.

Thanks.

>
> fwiw, I've never seen any valid BTF where:
> - the type_off is not 0, AND
> - the string_off is not equal to type_len
>
> and I believe some existing tools expect that both of these are true,
> even though it is not a requirement.

Considering BTF is related to BPF, that doesn't surprise me at all :P

> Of course it will be better to not rely on this though. :)

Yes I agree.  Otherwise, what are type_off and str_off for?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]