lkml.org 
[lkml]   [2018]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Handle clock_gettime(CLOCK_TAI) in VDSO
From
Date
On Tue, 2018-08-14 at 07:20 -0700, Andy Lutomirski wrote:
> > +       /* Doubled switch statement to work around kernel Makefile error */
> > +       /* See: https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg567499.html */
>
> NAK.
>
> The issue here (after reading that thread) is that, with our current
> compile options, gcc generates a jump table once the switch statement
> hits five entries.  And it uses retpolines for it, and somehow it
> generates the relocations in such a way that the vDSO build fails. 
> We
> need to address this so that the vDSO build is reliable, but there's
> an important question here:
>
> Should the vDSO be built with retpolines, or should it be built with
> indirect branches?  Or should we go out of our way to make sure that
> the vDSO contains neither retpolines nor indirect branches?
>
> We could accomplish the latter (sort of) by manually converting the
> switch into the appropriate if statements, but that's rather ugly.
>
> (Hmm.  We should add exports to directly read each clock source.
> They'll be noticeably faster, especially when
> cache-and-predictor-code.)

Surely it's kind of expected that the vDSO can't find an externally
provided __x86_indirect_thunk_rax symbol, since we only provide one as
part of the kernel image.

Building the vDSO with -mindirect-branch=thunk(|-inline) should fix
that, if we want retpolines in the vDSO.

There's also -fno-jump-tables.
[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2018-08-14 18:31    [W:0.043 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site