Page MenuHomePhabricator
Feed Advanced Search

Wed, Aug 3

anakryiko added a comment to D131012: No longer place const volatile global variables in a read only section.

This will severly break BPF users, as we have a heavy reliance on const volatile variables being allocated to .rodata, which are passed to BPF verifier in Linux kernel as read-only values. This is critical for BPF Complie Once - Run Everywhere approach of writing portable BPF applications. We've been relying on this behavior for years now and changes this will break many existing BPF applications.

Thank you for this feedback! I guess I'm a bit surprised given the contents from the issue seem to imply that BPF needed Clang's behavior to change: Note that this is causing practical difficulties: the kernel's bpftool is generating different skeleton headers for BPF code compiled from LLVM and GCC, because the names of the containing sections get reflected.

GCC folks are trying to make their BPF backend usable. But instead of working with community to make sure they do things the same way that Clang does (which for years now is de facto standard for compiling BPF code and we rely on this behavior heavily in libbpf and other BPF loader libraries), they instead work against BPF community and try to modify/adjust/break the world around them, instead of working with us to make GCC-BPF compatible with Clang.

Ah, that's background information I was unaware of. Thank you for sharing that perspective!

Wed, Aug 3, 10:45 AM · Restricted Project, Restricted Project
anakryiko added a comment to D131012: No longer place const volatile global variables in a read only section.

This will severly break BPF users, as we have a heavy reliance on const volatile variables being allocated to .rodata, which are passed to BPF verifier in Linux kernel as read-only values. This is critical for BPF Complie Once - Run Everywhere approach of writing portable BPF applications. We've been relying on this behavior for years now and changes this will break many existing BPF applications.

Thank you for this feedback! I guess I'm a bit surprised given the contents from the issue seem to imply that BPF needed Clang's behavior to change: Note that this is causing practical difficulties: the kernel's bpftool is generating different skeleton headers for BPF code compiled from LLVM and GCC, because the names of the containing sections get reflected.

Wed, Aug 3, 9:39 AM · Restricted Project, Restricted Project

Tue, Aug 2

anakryiko added a comment to D131012: No longer place const volatile global variables in a read only section.

This will severly break BPF users, as we have a heavy reliance on const volatile variables being allocated to .rodata, which are passed to BPF verifier in Linux kernel as read-only values. This is critical for BPF Complie Once - Run Everywhere approach of writing portable BPF applications. We've been relying on this behavior for years now and changes this will break many existing BPF applications.

Tue, Aug 2, 3:58 PM · Restricted Project, Restricted Project

Dec 15 2021

anakryiko added a comment to D111307: [clang] __attribute__ bpf_dominating_decl .

When dealing with some gross situation where a source generator is generating things that don't really work cleanly with the normal language, I have a strong preference for saying that the source generator should change. In this case, that would mean e.g. generating different type names in the generated headers. Is that really such a non-starter? This is really quite a terrible feature.

Dec 15 2021, 11:24 PM · Restricted Project

Nov 11 2021

anakryiko added a comment to D111307: [clang] __attribute__ bpf_dominating_decl .

I am okay with an explicit option to enable this attribute. I remembered in the past we discussed with a possible option -fpermissive to control this. But this may be too generic. Maybe an option like -Xclang -target-feature -Xclang +attr_bpf_dominating_decl? Just a rough idea.

Nov 11 2021, 10:08 AM · Restricted Project

Oct 19 2021

anakryiko accepted D112106: BPF: set .BTF and .BTF.ext section alignment to 4.

Great, thank you!

Oct 19 2021, 4:16 PM · Restricted Project

Oct 11 2021

anakryiko accepted D111592: BPF: rename BTF_KIND_TAG to BTF_KIND_DECL_TAG.

lgtm

Oct 11 2021, 6:32 PM · Restricted Project
anakryiko accepted D111591: [NFC][Attr] rename attribute btf_tag to btf_decl_tag.

lgmt

Oct 11 2021, 6:32 PM · Restricted Project
anakryiko accepted D111588: [Clang][Attr] rename btf_tag to btf_decl_tag.

lgtm

Oct 11 2021, 6:31 PM · Restricted Project

Sep 9 2021

anakryiko accepted D109560: BPF: change BTF_KIND_TAG format.
Sep 9 2021, 6:42 PM · Restricted Project

Aug 4 2021

anakryiko accepted D107483: BPF: avoid NE/EQ loop exit condition.

I've hit similar issue in the past and it's a very frustrating experience having to work around that. So thumbs up for preventing this!

Aug 4 2021, 1:27 PM · Restricted Project

Aug 3 2021

anakryiko added a comment to D106614: [Clang] add btf_tag attribute.

I think it's reasonable behavior to just merge all bpf_tags across declaration(s) and a definition. Kind of like __weak behaves, it doesn't matter if it's on actual function or its extern declaration.

Aug 3 2021, 12:35 PM · Restricted Project, debug-info

Aug 2 2021

anakryiko accepted D106622: [BPF] support btf_tag attribute in .BTF section.

LGTM from the BTF definition standpoint.

Aug 2 2021, 12:48 PM · Restricted Project

Jul 27 2021

anakryiko added inline comments to D106622: [BPF] support btf_tag attribute in .BTF section.
Jul 27 2021, 4:03 PM · Restricted Project
anakryiko added inline comments to D106621: [DWARF] Support new TAG DW_TAG_LLVM_annotation.
Jul 27 2021, 3:04 PM · Restricted Project, debug-info
anakryiko added inline comments to D106614: [Clang] add btf_tag attribute.
Jul 27 2021, 3:00 PM · Restricted Project, debug-info

May 6 2021

anakryiko added a comment to D102036: BPF: fix FIELD_EXISTS relocation with array subscripts.

But bar[1] is not a field, why can't we just return error for such case? If someone wants to check type existence we have a separate TYPE_EXISTS relocation.

May 6 2021, 10:44 PM · Restricted Project

Apr 19 2021

anakryiko accepted D100568: BPF: generate BTF info for LD_imm64 loaded function pointer.
Apr 19 2021, 10:28 AM · Restricted Project

Apr 15 2021

anakryiko accepted D100567: BPF: emit debuginfo for Function of DeclRefExpr if requested.

Nice, thanks! This will work for externs with explicit section name (.ksym) and with no section name (externs for static linking), right?

Apr 15 2021, 1:12 PM · Restricted Project, debug-info

Apr 13 2021

anakryiko accepted D100392: BPF: remove default .extern data section.

LGTM, thanks!

Apr 13 2021, 10:36 AM · Restricted Project

Mar 4 2021

anakryiko added inline comments to D97986: BPF: permit type modifiers for __builtin_btf_type_id() relocation.
Mar 4 2021, 3:57 PM · Restricted Project
anakryiko added inline comments to D97986: BPF: permit type modifiers for __builtin_btf_type_id() relocation.
Mar 4 2021, 3:25 PM · Restricted Project

Feb 8 2021

anakryiko added a comment to D83289: [BPF] Add support for floats and doubles.
In D83289#2549050, @iii wrote:

Hi, it has been a long time, but I've finally implemented the support
for the floating-point types in BTF. Here are the other pieces:

Feb 8 2021, 5:48 PM · Restricted Project

Dec 19 2020

anakryiko added a comment to D93563: BPF: add extern func to data sections if specified.

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.

Dec 19 2020, 12:54 PM · Restricted Project

Nov 15 2020

anakryiko added inline comments to D91489: BPF: make __builtin_btf_type_id() return 64bit int.
Nov 15 2020, 1:02 PM · Restricted Project, Restricted Project

Aug 4 2020

anakryiko added a comment to D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

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.

typedef t and struct t are also different for field relocations (those t is in different namespaces, actually), so it might be a good idea to disambiguate those for field relocations as well?

Just to be clear. The type recorded in relocation will be always valid since we have type_id there. For field exists, due to we may use nullptr as the object, if CSE happens, it is possible the root type id may be the "struct t" instead of "typedef t" (or the other ordering) assuming the definition "typedef struct t t;". But from root type_id, libbpf will be able to correctly trace down to the field and do the relocation properly.

On the other hand, I agree that this is not ideal as we may use a different root type than what user specified in the source. But everything is hidden and invisible to user so I won't have user visible impact.

Aug 4 2020, 11:58 PM · Restricted Project, Restricted Project
anakryiko added a comment to D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

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 4 2020, 11:05 AM · Restricted Project, Restricted Project

Aug 3 2020

anakryiko accepted D85174: BPF: simplify IR generation for __builtin_btf_type_id().

Tested locally. Previously failing tests are now passing. All recorded relocations look correct. Thanks!

Aug 3 2020, 5:52 PM · Restricted Project, Restricted Project
anakryiko accepted D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

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?

Aug 3 2020, 4:29 PM · Restricted Project, Restricted Project
anakryiko accepted D83878: BPF: support type exist/size and enum exist/value relocations.

Looks good. I've tested locally all this and it works as expected. Thanks!

Aug 3 2020, 4:18 PM · Restricted Project

Jul 30 2020

anakryiko added inline comments to D83878: BPF: support type exist/size and enum exist/value relocations.
Jul 30 2020, 12:24 PM · Restricted Project
anakryiko accepted D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

looks great, I'll complete libbpf support for all these ASAP

Jul 30 2020, 12:17 PM · Restricted Project, Restricted Project

Jul 22 2020

anakryiko added a comment to D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

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 22 2020, 12:55 PM · Restricted Project, Restricted Project

Jul 16 2020

anakryiko accepted D84002: BPF: generate .rodata BTF datasec for certain initialized local var's.

Thanks for the fix! LGTM.

Jul 16 2020, 11:00 PM · Restricted Project

Jul 15 2020

anakryiko added a comment to D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

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 15 2020, 1:14 PM · Restricted Project, Restricted Project

Jul 12 2020

anakryiko accepted D83638: BPF: permit .maps section variables with typedef type.

ah, makes sense. LGTM then :)

Jul 12 2020, 12:31 AM · Restricted Project

Jul 11 2020

anakryiko added a comment to D83638: BPF: permit .maps section variables with typedef type.

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 11 2020, 11:17 PM · Restricted Project

Jul 10 2020

anakryiko added a comment to D83289: [BPF] Add support for floats and doubles.

I concur with @yonghong-song, making float disappear is much bigger pain.

Jul 10 2020, 2:59 PM · Restricted Project
anakryiko added a comment to D83289: [BPF] Add support for floats and doubles.

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 10 2020, 1:00 PM · Restricted Project

Jul 6 2020

anakryiko added a comment to D83242: [clang][BPF] support type exist/size and enum exist/value relocations.

Awesome, that's exactly what we need for BPF helper availability checks!

Jul 6 2020, 1:37 PM · Restricted Project, Restricted Project

Jun 17 2020

anakryiko added inline comments to D82041: [BPF] fix a bug for BTF pointee type pruning.
Jun 17 2020, 12:56 PM · Restricted Project

Jun 9 2020

anakryiko added a comment to D72787: [BPF] Adjust optimizations to generate kernel verifier friendly codes.

V >= Lo && V < Hi --> V - Lo u< Hi - Lo
V < Lo || V >= Hi --> V - Lo u>= Hi - Lo

Jun 9 2020, 7:20 PM · Restricted Project
anakryiko added a comment to D81479: [BPF] introduce __builtin_bpf_load_u32_to_ptr() intrinsic.

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 9 2020, 2:54 PM · Restricted Project, Restricted Project

Jun 3 2020

anakryiko accepted D81131: [DebugInfo] Fix assertion for extern void type.

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 :)

Jun 3 2020, 11:02 PM · Restricted Project, Restricted Project, debug-info

May 5 2020

anakryiko added a comment to D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function.

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?

Originally, I thought flag = 0 for the following use case:

e.g., they just want to know the type of a particular local structure for pretty print purpose.
Note that currently only types for global/extern variables, function parameters are recorded in btf.
  int test() {
     struct { int a; int b; ...} ctx;
     btf_id = __builtin_btf_type_id(ctx, 0);
     bpf_seq_write(seq, &btf_id, sizeof(btf_id));
     bpf_seq_write(seq, &ctx, sizeof(ctx));
     ...
  }

But obviously without relocation, this will not work with btf deduplication, future static linking etc.

May 5 2020, 11:53 AM · debug-info, Restricted Project, Restricted Project

May 4 2020

anakryiko added a comment to D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function.

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 4 2020, 11:57 PM · debug-info, Restricted Project, Restricted Project

May 1 2020

anakryiko added a comment to D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function.

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?

May 1 2020, 5:11 PM · debug-info, Restricted Project, Restricted Project

Feb 4 2020

anakryiko accepted D73997: [BPF] disable ReduceLoadWidth during SelectionDag phase.

looks simple enough, thanks for fixing it fast!

Feb 4 2020, 3:09 PM · Restricted Project
anakryiko accepted D73902: [BPF] handle typedef of struct/union for CO-RE relocations.
Feb 4 2020, 8:31 AM · Restricted Project

Feb 3 2020

anakryiko accepted D73900: [BPF] use base lvalue type for preserve_{struct,union}_access_index metadata.

lgtm

Feb 3 2020, 10:02 AM · Restricted Project
anakryiko added inline comments to D73902: [BPF] handle typedef of struct/union for CO-RE relocations.
Feb 3 2020, 9:47 AM · Restricted Project

Dec 21 2019

anakryiko accepted D71790: [BPF] Enable relocation location for load/store/shifts.

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 21 2019, 8:31 PM · Restricted Project

Dec 10 2019

anakryiko accepted D71290: [BPF] put not-section-attribute externs into BTF ".extern" data section.

awesome, thanks!

Dec 10 2019, 11:23 AM · Restricted Project

Nov 12 2019

anakryiko accepted D70145: [BPF] generate BTF_KIND_VARs for all non-static globals.

looks good, thanks!

Nov 12 2019, 2:12 PM · Restricted Project

Oct 21 2019

anakryiko added a comment to D68822: [BPF] Support external globals.

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.

Oct 21 2019, 8:41 PM · Restricted Project
anakryiko added a comment to D68822: [BPF] Support external globals.

Also, another thing. we COULD emit debug info type for externs for BPF in clang. We just have to think whether this is really necessary or not.

Oct 21 2019, 8:41 PM · Restricted Project
anakryiko added a comment to D68822: [BPF] Support external globals.

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 21 2019, 8:13 PM · Restricted Project

Oct 11 2019

anakryiko added inline comments to D68822: [BPF] Support external globals.
Oct 11 2019, 3:38 PM · Restricted Project

Oct 2 2019

anakryiko added inline comments to D67980: [BPF] do compile-once run-everywhere relocation for bitfields.
Oct 2 2019, 9:18 PM · Restricted Project, Restricted Project

Sep 24 2019

anakryiko accepted D67979: [BPF] Generate array dimension size properly for zero-size elements.

Looks good, thanks for fixing so fast!

Sep 24 2019, 2:26 PM · Restricted Project