Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software events

[Peter Zijlstra]

On Mon, Aug 30, 2021 at 04:36:44PM +0000, Song Liu wrote:

> > /*
> > * Static call support
> > *
> > * Static calls use code patching to hard-code function pointers into direct
> > * branch instructions. They give the flexibility of function pointers, but
> > * with improved performance. This is especially important for cases where
> > * retpolines would otherwise be used, as retpolines can significantly impact
> > * performance.
> > *
> 
> [...]
> 
> > *
> > * Notes on NULL function pointers:
> > *
> > *   Static_call()s support NULL functions, with many of the caveats that
> > *   regular function pointers have.
> > *
> > *   Clearly calling a NULL function pointer is 'BAD', so too for
> > *   static_call()s (although when HAVE_STATIC_CALL it might not be immediately
> > *   fatal). A NULL static_call can be the result of:
> > *
> 
> Probably add:
> 
>  *     /* for function that returns NULL */
> > *     DECLARE_STATIC_CALL_NULL(my_static_call, void (*)(int));
> 
> 
>  *   or 
>  *     /* for function that returns int */
>  *     DECLARE_STATIC_CALL_RET0(my_static_call, int (*)(int));
>  * 

No, anything that uses static_call_cond() must have void return. Note
that static_call_cond() replaces:

	if (func_ptr)
		func_ptr(args);

which is a statement, not an expression, and as such can't function as
an rvalue.

> So it is clear that we need two different macros. IIUC, the number and 
> type of arguments doesn't matter? 

Right, arguments are irrelevant, provided CDECL ABI, which mandates that
arguments that are pushed on the stack are cleaned up by the caller, not
the callee.

> Also, the default return int function has to return 0, right? Can we let 
> it return -EOPNOSUPP? 

Difficult, in principle we can patch any value that fits in a single
instruction, but the more variants we have, the harder it gets.