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<a...@firstfloor.org>
Date: 17 March 2018 at 23:00
To: jason.vas.d...@gmail.com
Cc: linux-ker...@vger.kernel.org, x...@kernel.org, t...@linutronix.de,
mi...@kernel.org, pet...@infradead.org, a...@firstfloor.org
>On Sat, Mar 17, 2018 at 02:29:34PM +0000, jason.vas.d...@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
