linux/bpf: regenerate help function with alignment to make compiler happy

[tw4452852]

No description provided.

[rohlem]

Does it still make sense then that the default alignment for function pointers on BPF targets is > 1?
Do user-provided functions have a higher alignment restriction than these special helper functions?

[tw4452852]

Does it still make sense then that the default alignment for function pointers on BPF targets is > 1?

I don't think so.

Do user-provided functions have a higher alignment restriction than these special helper functions?

Yes, I think for these ones that could be align(sizeof(usize))

[alexrp]

Does it still make sense then that the default alignment for function pointers on BPF targets is > 1?

We match GCC and LLVM here. If we're going to change this, especially when we use LLVM as our code generator for this target, I would like to see some evidence that changing it won't cause subtle linker bugs.

[tw4452852]

I did an experiment with clang as follows:

> cat t.c

static long (* const bpf_trace_printk)(const char *fmt, int fmt_size, ...) = (void *) 6;

int foo(void) {
        bpf_trace_printk("bar", 3);
        return 0;
}

> clang -S --target=bpfel-freestanding -emit-llvm t.c
> cat t.ll

; ModuleID = 't.c'
source_filename = "t.c"
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "bpfel-freestanding"

@.str = private unnamed_addr constant [4 x i8] c"bar\00", align 1

; Function Attrs: noinline nounwind optnone
define dso_local i32 @foo() #0 {
  %1 = call i64 (ptr, i32, ...) inttoptr (i64 6 to ptr)(ptr noundef @.str, i32 noundef 3)
  ret i32 0
}

attributes #0 = { noinline nounwind optnone "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" }

!llvm.module.flags = !{!0, !1}
!llvm.ident = !{!2}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"frame-pointer", i32 2}
!2 = !{!"clang version 17.0.6"}

[alexrp]

Can you clarify what you're trying to show?

[tw4452852]

%1 = call i64 (ptr, i32, ...) inttoptr (i64 6 to ptr)(ptr noundef @.str, i32 noundef 3)

LLVM use inttoptr to cast, I think it doesn't assume any alignment requirement. Feel free to correct me.

[alexrp]

Well, sure; C and LLVM IR don't represent pointer alignment in the type system like Zig does. So that in itself isn't surprising.

But changing the default function alignment often has broader ABI ramifications. In some cases, the linker may depend on a certain minimum function alignment in order to produce correct binaries. (I don't know if that's the case for BPF.) Here's the relevant code in GCC and LLVM:

• https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.h;h=2298e5b05afd94e481d310b3463a020b0c161c62;hb=HEAD#l63
• https://github.com/llvm/llvm-project/blob/dd98ae358b187be32a2e255eba5f91568524b86a/llvm/lib/Target/BPF/BPFISelLowering.cpp#L155-L157

[tw4452852]

Updated with @InKryption 's suggestion.

@alexrp There two things here to make BPF unusual:

• BPF helpers are just a dummy call, according to the manual:

Internally, eBPF programs call directly into the compiled helper
functions without requiring any foreign-function interface. As a
result, calling helpers introduces no overhead, thus offering
excellent performance.

• BPF programs are usually generated w/o linking, they are only being compiled(Currently no compiler supports linking BPF programs). Here's the example from linux kernel.