[PATCH v2] arm64: implement support for static call trampolines

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 12:54, Quentin Perret <qperret at google.com> wrote:
>
> On Thursday 29 Oct 2020 at 12:32:50 (+0100), Ard Biesheuvel wrote:
> > We'll need tooling along the lines of the GCC plugin I wrote [0] to
> > implement inline static calls - doing function calls from inline
> > assembly is too messy, too fragile and too error prone to rely on.
>
> Right, and that is the gut feeling I had too, but I can't quite put my
> finger on what exactly can go wrong. Any pointers?
>

The main problem is that the compiler is not aware that a function
call is being made. For instance, this code

int fred(int l)
{
asm("bl barney"
:"+r"(l)
::"x1", "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9",
  "x10", "x11", "x12", "x13", "x14", "x15", "x16", "x17", "x30",
  "cc");

return l + 1;
}

works with GCC, but only if I omit the x29 clobber, or it gives an
error. With that omitted, Clang produces

.type fred, at function
fred:                                   // @fred
// %bb.0:
str x30, [sp, #-16]!        // 8-byte Folded Spill
//APP
bl barney
//NO_APP
add w0, w0, #1              // =1
ldr x30, [sp], #16          // 8-byte Folded Reload
ret

i.e., it does not set up the stack frame correctly, and so we lose the
ability to unwind the stack through this call.

There may be some other corner cases, although I agree it makes sense
to get to the bottom of this.


> > However, as I discussed with Will offline yesterday as well, the
> > question that got snowed under is whether we need any of this on arm64
> > in the first place. It seems highly unlikely that inline static calls
> > are worth it, and even out-of-line static calls are probably not worth
> > the hassle as we don't have the retpoline problem.
> >
> > So this code should be considered an invitation for discussion, and
> > perhaps someone can invent a use case where benchmarks can show a
> > worthwhile improvement. But let's not get ahead of ourselves.
>
> The reason I'm interested in this is because Android makes heavy use of
> trace points/hooks, so any potential improvement in this area would be
> welcome. Now I agree we need numbers to show the benefit is real before
> this can be considered for inclusion in the kernel. I'll try and see if
> we can get something.
>
> Thanks,
> Quentin