> > > 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'? 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.) 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)
