On Thu, May 07, 2020 at 04:55:24PM +0100, Will Deacon wrote:
> On Thu, May 07, 2020 at 04:48:54PM +0100, Mark Brown wrote:

> > Right, I'm seeing it here now - it's when CONFIG_GCOV_KERNEL is enabled
> > and happens for clang-10 as well but not a GCC 10 prerelease build.

> Interesting. Is that because GCC doesn't emit out-of-line GCOV functions,
> or does it emit PAC/BTI instructions for them instead? (you can disassemble
> one of the problematic opjects to have a look).

GCC does emit some helper functions wrapping GCOV stuff but they have
appropriate annotations, eg:

00000000000000ac <_sub_D_00100_1>:
  ac:	d503245f 	bti	c
  b0:	a9bf7bfd 	stp	x29, x30, [sp, #-16]!
  b4:	910003fd 	mov	x29, sp
  b8:	94000000 	bl	0 <__gcov_exit>
  bc:	a8c17bfd 	ldp	x29, x30, [sp], #16
  c0:	d65f03c0 	ret

I can also reproduce this for clang with a trivial standalone source
file and -fprofile-arcs -mbranch-protection=bti so it's nothing funky
the kernel is doing as far as I can see.

> I can't immediately see how to fix it, so your hack above might be the best
> bet for now. I'm just a little wary that it might not be limited to GCOV,
> but rather anything where the compiler provides a form of runtime.

Indeed.  I guess the nice thing with BTI is that if something goes wrong
it will do so rather visibly so unless there are situations where the
toolchain emits rarely called functions the problems will tend to be
very obvious, and it seems that clang is detecting the problem itself
and complaining loudly which makes it even more likely that if something
else is affected it'll be noticed and we can at least add similar
bodges.

It does seem it's a straight compiler issue, if the compiler is emitting
runtime then the compiler ought to be ensuring that it agrees with the
build options the compiler was given and I can't think how this would be
fixable or avoidable outside of the compiler other than "don't do that"
which is what my Kconfig bodge did.  I'm talking to the toolchain people
internally about this.