- User Since
- May 24 2019, 12:23 PM (87 w, 2 d)
Dec 19 2020
Having an explicit special section for extern functions clearly indicating the intent (that it should match kernel function) is really good. Especially with static linking. Otherwise, this "try local function, otherwise fallback to kernel function" is going to be really painful for users if there is any error, because all such errors will be indicated at the load time instead of at the link time, where they should be detected and reported.
Nov 15 2020
Aug 4 2020
This is different than testing whether a type exists or not where we want to precisely test whether that type exists or not, so we want to preserve typedef type vs. struct t type.
Aug 3 2020
Tested locally. Previously failing tests are now passing. All recorded relocations look correct. Thanks!
LGTM. One question: why didn't we run into the need for SeqNumVal trick with field-based relocations? We seem to need it for all other types (including type ID-based), but not for field-based?
Looks good. I've tested locally all this and it works as expected. Thanks!
Jul 30 2020
looks great, I'll complete libbpf support for all these ASAP
Jul 22 2020
After thinking about this a bit more, I think adding a new TYPE_EXISTENCE (instead of FIELD_EXISTENCE) relocation type is the better way to handle this. It would allow Clang to be stricter as to what is passed into FIELD_EXISTENCE (only fields, not types) vs TYPE_EXISTENCE(only types, no fields). It will make it cleaner on libbpf side as well, because the validation and relocation logic is different between handling fields and types. So overall, I think it will be beneficial on every level of the stack to separate them. I hope it's not too hard to make this change?
Jul 16 2020
Thanks for the fix! LGTM.
Jul 15 2020
This is awesome. I'll apply patches locally and will play with them tonight to see if everything works in libbpf as well. Thanks!
Jul 12 2020
ah, makes sense. LGTM then :)
Jul 11 2020
maybe let's just remove special-casing of .maps section? It's just like any other global variable, should be handled in exactly the same way, no?
Jul 10 2020
I concur with @yonghong-song, making float disappear is much bigger pain.
pahole does a sensible thing, it represents it as BTF_KIND_INT (which maps to DWARF's DW_TAG_base_type), but with no encoding (so it's effectively unsigned integer with proper size).
Jul 6 2020
Awesome, that's exactly what we need for BPF helper availability checks!
Jun 17 2020
Jun 9 2020
V >= Lo && V < Hi --> V - Lo u< Hi - Lo
V < Lo || V >= Hi --> V - Lo u>= Hi - Lo
IntrinsicsBPF.td uses __builtin_bpf_load_u32_to_ptr, while everywhere it is just __builtin_load_u32_to_ptr. I think having bpf prefix there is good, given this is bpf-specific. But either way, probably should be consistent everywhere?
Jun 3 2020
For my purposes, having extern var BTF only for extern const void is just fine. Not crashing Clang for extern void is great as well :)
May 5 2020
May 4 2020
what's the use case for flag==0 (no relocation)? why using built-in at all in such case? Also flag==1 means relocate to local BTF ID or remote (kernel) BTF ID? Do you plan to add flag=2 as well to cover both cases? Or am I misunderstanding the meaning of this flag?
May 1 2020
Let's extend __builtin_btf_type_id() to accept second argument specifying whether it's local BTF ID (from program's BTF) or target BTF ID (from kernel/module BTF)? We can probably make it an enum just like with preserve_access_index() built-in, for easy future extension. WDYT?
Feb 4 2020
looks simple enough, thanks for fixing it fast!
Feb 3 2020
Dec 21 2019
I implemented libbpf relocation patching support for new classes of instructions and tested against kernel selftests and runqslower program. All of those pass. Thanks a lot, this is going to improve BPF CO-RE experience immensely!
Dec 10 2019
Nov 12 2019
looks good, thanks!
Oct 21 2019
hm... size is useful, actually. Ok, let me play with it, it's hard to get a good idea of BTF from LLVM tests. Verifier will definitely reject such variables, though, so we'll need to do sanitization for sure.
if there is no type information available for extern variables, there is little benefit in having them as DATASEC+VAR. No size, no type. We can get the same information from ELF itself without having to teach verifier and libbpf how to handle these new types. Let's drop this for now? The only potential benefit is having a section name associated with extern, but we can either add that later, or even add it in a way that will require no verifier changes - BTF.ext.
Oct 11 2019
Oct 2 2019
Sep 24 2019
Looks good, thanks for fixing so fast!