Eduard Zingerman <eddyz87@xxxxxxxxx> writes:
> On Fri, 2024-11-08 at 21:43 +0100, Toke Høiland-Jørgensen wrote:
>> Eduard Zingerman <eddyz87@xxxxxxxxx> writes:
>>
>> > Inlinable kfuncs are available only if CLANG is used for kernel
>> > compilation.
>>
>> To what extent is this a fundamental limitation? AFAIU, this comes from
>> the fact that you are re-using the intermediate compilation stages,
>> right?
>
> Yes, the main obstacle is C --clang--> bitcode as for host --llc--> BPF pipeline.
> And this intermediate step is needed to include some of the header
> files as-is (but not all will work, e.g. those where host inline
> assembly is not dead-code-eliminated by optimizer would error out).
> The reason why 'clang --target=bpf' can't be used with these headers
> is that headers check current architecture in various places, however:
> - there is no BPF architecture defined at the moment;
> - most of the time host architecture is what's needed, e.g.
> here is a fragment of arch/x86/include/asm/current.h:
>
> struct pcpu_hot {
> union {
> struct {
> struct task_struct *current_task;
> int preempt_count;
> int cpu_number;
> #ifdef CONFIG_MITIGATION_CALL_DEPTH_TRACKING
> u64 call_depth;
> #endif
> unsigned long top_of_stack;
> void *hardirq_stack_ptr;
> u16 softirq_pending;
> #ifdef CONFIG_X86_64
> bool hardirq_stack_inuse;
> #else
> void *softirq_stack_ptr;
> #endif
> };
> u8 pad[64];
> };
> };
>
> In case if inlinable kfunc operates on pcpu_hot structure,
> it has to see same binary layout as the host.
> So, technically, 'llc' step is not necessary, but if it is not present
> something else should be done about header files.
Right, makes sense. Do any of the kfuncs you are targeting currently use
headers that have this problem? If not, could a stopgap solution be to
just restrict the set of kfuncs that can be inlined to those that can be
compiled with `clang --target=bpf`? That may require moving around some
code a bit, but there are other examples where all the kfuncs for a
subsystem are kept in a separate .c file anyway (IIRC, netfilter does this).
>> But if those are absent, couldn't we just invoke a full clang
>> compile from source of the same file (so you could get the inlining even
>> when compiling with GCC)?
>
> Yes, hybrid should work w/o problems if headers are dealt with in some
> other way.
But couldn't a hybrid approach be used even in the case of GCC
compilation? I.e., compile it both with GCC (for inclusion into
vmlinux/.ko file) and once with clang (in host mode) and then pass it
through LLC to generate BPF?
-Toke
