Re: FAILED unresolved symbol vfs_truncate on arm64 with LLVM

On Wed, Feb 10, 2021 at 11:34:25AM +0000, David Laight wrote:

quoted

quoted

quoted

vfs_truncate disasm:

        ffff80001031f430 <vfs_truncate>:
        ffff80001031f430: 5f 24 03 d5   hint    #34
        ffff80001031f434: 1f 20 03 d5   nop
        ffff80001031f438: 1f 20 03 d5   nop
        ffff80001031f43c: 3f 23 03 d5   hint    #25

thats why we don't match it in pahole.. I checked few other functions
and some have the same problem and some match the function boundary

those that match don't have that first hint instrucion, like:

        ffff800010321e40 <do_faccessat>:
        ffff800010321e40: 1f 20 03 d5   nop
        ffff800010321e44: 1f 20 03 d5   nop
        ffff800010321e48: 3f 23 03 d5   hint    #25

any hints about hint instructions? ;-)

aarch64 makes *some* newer instructions reuse the "hint" ie "nop"
encoding space to make software backwards compatible on older hardware
that doesn't support such instructions.  Is this BTI, perhaps? (The
function is perhaps the destination of an indirect call?)

It seems like it. The issue is not reproducible when
CONFIG_ARM64_BTI_KERNEL is not set.

Is the compiler/linker doing something 'crazy'?

I need to check the gcc build, where pahole in my test sees
zero ftrace addresses, while booted kernel shows ftrace working

If a function address is taken then the BTI instruction is placed
before the function body and the symbol moved.
But non-indirect calls still jump to the original start of the function.
(In this case the first nop.)

for clang build, it looks like pahole needs fix not to assume that
ftrace address match with function start, I'll send it later today

thanks,
jirka

This saves the execution time of the BTI instruction for non-indirect
calls.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)