Re: [RFC bpf-next 03/11] bpf: shared BPF/native kfuncs

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2024-11-08 at 21:43 +0100, Toke Høiland-Jørgensen wrote:
> Eduard Zingerman <eddyz87@gmail.com> 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.

> 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.