[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]

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

--- Comment #2 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
Thanks H.J. -

RE:
> vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> 4.16-rc5.  Why isn't it the case for you? 

All I know is ,  when submitting a patched vclock_gettime.c 
in which the switch in vdso_clock_gettime() had 6 clauses
instead of 5, I received in response a mail from 
kbuild test robot<lkp@intel.com>:

>Hi
>
>Thank you for the patch! Yet something to improve:
>
>[auto build test ERROR on v4.16-rc4]
>[also build test ERROR on next-20180315]
>[if your patch is applied to the wrong git tree, please drop us a note to help >improve the system]
>
>url:    https://github.com/0day-ci/linux/commits/jason-vas-dias-gmail-com/x86-vdso-on-Intel-VDSO-should-handle-CLOCK_MONOTONIC_RAW/20180316-070319
>config: x86_64-rhel (attached as .config)
>compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>reproduce:
>        # save the attached .config to linux build tree
>        make ARCH=x86_64
>
>All errors (new ones prefixed by >>):
>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 >against undefined symbol `__x86_indirect_thunk_rax' can not be used when making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---
>0-DAY kernel test infrastructure                Open Source Technology Center
>https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

That github URL does not point to anything anymore.

So it was 4.16-rc4 they were compiling against.
Maybe it is fixed in 4.16-rc5.

I had seen exactly the same problem when compiling the same
patch with the RHEL-7 4.8.5-16-el7_4.2.x86_64 compiler,
which did not happen when compiling the same code with
the previous RHEL-7 4.8.5-16-el7_4.1.x86_64 compiler.

So it is caused by  -mindirect-branch=thunk-extern ?


Aha, I see in kernel Makefile of the RHEL 3.10.0-21.1.el7 kernel:
  RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern
-mindirect-branch-register)

And it is still in the CFLAGS of the kernel tagged 'v4.16-rc5:'

$ grep RETPOLINE linux-4.16-rc5/Makefile
RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
-mindirect-branch-register
RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call
cc-option,$(RETPOLINE_CFLAGS_CLANG)))

But the compiler I am using for the 4.x builds is 6.4.1 , which
does not support -mindirect-branch=thunk-extern / -mindirect-branch-register .

I will get round to building one of the latest compilers with
retpoline support eventually, but it is not a priority for me
at the moment, for my Linux 4.x builds.

I just want to be able to build the patched vclock_gettime.c
under RHEL, with the new 4.8.5-16 retpoline supporting compiler,
and to be able to submit patches that don't break to the 4.16-rc5
branch .


YES, I have just tested, removing 
  '-mindirect-branch=thunk-extern -mindirect-branch-register'
from the 3.10.0-693.21.1.el7 build DOES allow it to succeed 
with the 6-clause version of the switch in vclock_gettime.c .

But I don't want my patch to have to depend on this being removed -
the removal of these flags effectively removes retpoline support, no ?
It is a shame to have to do that after it was carefully added.

My gripe is really that nothing in GCC should work with a switch
with < 6 clauses, and fail with a switch with >= 6 clauses.

Just reporting this issue so it can be fixed.

Thanks & Best Regards,
Jason