[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

["jason.vas.dias at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #14 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---


RE: Comment #13:
> You said that Andi Kleen had a comment.  Can you point me to it?

Here is a quote, from LKML message :

Subject: Re: [PATCH v4.16-rc5 2/2] x86/vdso: \
         VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) \
         without syscall   Kernel 
From: Andi Kleen<andi@firstfloor.org>   
Date: 17 March 2018 at 23:00
To: jason.vas.dias@gmail.com
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
mingo@kernel.org, peterz@infradead.org, andi@firstfloor.org


>On Sat, Mar 17, 2018 at 02:29:34PM +0000, jason.vas.dias@gmail.com wrote:
>>          This patch allows compilation to succeed with compilers that 
>>          support -DRETPOLINE -
>>          it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 :
>>             https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
>>
>>          Apparently the GCC retpoline implementation has a limitation 
>>          that it cannot handle switch statements with more than 5 clauses,
>>          which vclock_gettime.c's
>>         __vdso_clock_gettime function now conts.
>
>That's quite a mischaracterization of the issue. gcc works as intended,
>but the kernel did not correctly supply a indirect call retpoline thunk
>to the vdso, and it just happened to work by accident with the old
>vdso.
>
>>
>>          The automated test builds should now succeed with this patch.
>
>How about just adding the thunk function to the vdso object instead of
>this cheap hack?
>
>The other option would be to build vdso with inline thunks.
>
>But just disabling is completely the wrong action.
>
>-Andi

So, in their wisdom, the kernel developers have decided it is
best to compile the VDSO with indirect-branch("thunk-extern,register"),
and we need to work around the limitations this imposes.

RE: Comment #13:
> I also think that static inlines have anything to do with it.  
> Nor so I see why any function attributes make any sense.

On the contrary, I think function attributes and static inline-ness
have ALOT to do with it - the problem does not occur if the 
called functions have the SAME indirect-branch attributes as
the caller function, or if the called function is not static inline.

It definitely appears to be something to do with GCC having to
instantiate a callable version of a static inline, when that
inline has different indirect-branch attributes than its caller.

The '-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE'
flags should have the effect of making the default function attributes to be
  '__attribute__((indirect-branch("thunk-extern,register"))'
for any function that does not specify other indirect-branch attributes,
so when instantiating this callable version of the inline GCC needs to
generate a thunk-extern relocation. The code which produces the special
stripped & augmented version of the VDSO object does not include support for
such relocations and complains about them, failing the builds.


I also have many unanswered questions about this bug, mentioned above -
perhaps H.J. could clarify ? :
o why exactly is it that the 6-clause switch in the first post triggers
  the relocation, and the 5-clause switch does not?
  why cannot this limitation be removed from GCC?
o why should GCC be trying to generate an extern thunk for 
  an indirect branch to a static inline function anyway ? 
  I think static-inlineness should always trump
indirect-branch("thunk-extern").
o GCC appears to provide no way for users to construct their own jump tables
  without relocations - why does every reference to a PC-relative label
  produce a relocation?





I do believe this