[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?