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.
smime.p7s
Description: S/MIME cryptographic signature
