search for: __x86_indirect_thunk_

...nsequence, DSOs built with two versions of LLVM (or LLVM and GCC) with different thunk behavior and each will find the correct thunk. That was a specific part of the design. While you *can* export your external thunk, that's a choice of the code defining the thunk. > > You can even use __x86_indirect_thunk_\reg for *now* and reserve the > right to use a different name if you ever do revise the ABI. > Maybe I don't understand, but I'm surprised that there is a significant burden to having aliases for now instead? -------------- next part -------------- An HTML attachment was scrubbed......

...reat. Alternatively, Guenter or > > someone else here can help. > > Hm, please could we also have the %V asm constraint modifier? That > allows us to emit calls to the thunks from inline asm using the > register that the compiler chose for us: > > asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : : > [thunk_target] "r" (the_function)); > > Other than that, I get the following errors with LLVM+Clang master, and > my tree at > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb > I tried ToT clang with Lin...

...#39;. There's not a lot of scope for a 'v2' of that, surely? I could live with the command-line divergence, although it's suboptimal. But *please* since these things also need to be symbols exported to loadable modules, can't we keep the thunk names identical? You can even use __x86_indirect_thunk_\reg for *now* and reserve the right to use a different name if you ever do revise the ABI. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <http://lists.llvm.org/pipermail...

...> code defining the thunk. The driving force in the kernel is to be able to runtime patch the thunks away, when running on a CPU or in a mode that doesn't need them. We really want to have central implementations and have everything use them. > > > > > > You can even use __x86_indirect_thunk_\reg for *now* and reserve the > > > > right to use a different name if you ever do revise the ABI.> > Maybe I don't understand, but I'm surprised that there is a significant burden to having aliases for now instead?  > You can make that work within the kernel image i...

...'s this for a test? ; RUN: llc < %s -mtriple=i686-- -no-integrated-as | FileCheck -check-prefix=X86 %s ; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck -check-prefix=X64 %s ; If the target does not have 64-bit integer registers, emit 32-bit register ; names. ; X86: calll __x86_indirect_thunk_e{{[abcd]}}x ; X64: callq __x86_indirect_thunk_r define void @q_modifier(i32* %p) { entry:   tail call void asm sideeffect "call __x86_indirect_thunk_${0:V}", "r,~{dirflag},~{fpsr},~{flags}"(i32* %p)   ret void } -------------- next part -------------- A non-text attachment was...

..., 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > Hm, please could we also have the %V asm constraint modifier? That > > allows us to emit calls to the thunks from inline asm using the > > register that the compiler chose for us: > > > >  asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : : > > [thunk_target] "r" (the_function));  > > > > Other than that, I get the following errors with LLVM+Clang master, and > > my tree at > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb > &gt...

On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote: > > > > I saw the retpoline mitigation landed in r323155. Are we ready to > > merge this to 6.0, or are there any open issues that we're waiting > > for? Also, were there any followups I should know about? Also,

I'll save you a review iteration. This is updated to match llvm coding style. Capital camel case variable names and uses LLVM_FALLTHROUGH instead of the comment. static bool printAsmMRegister(X86AsmPrinter &P, const MachineOperand &MO, char Mode, raw_ostream &O) { unsigned Reg = MO.getReg(); + bool EmitPercent = true; + switch (Mode) {

...u're up for that, it would be great. Alternatively, Guenter or > someone else here can help. Hm, please could we also have the %V asm constraint modifier? That allows us to emit calls to the thunks from inline asm using the register that the compiler chose for us: asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : : [thunk_target] "r" (the_function)); Other than that, I get the following errors with LLVM+Clang master, and my tree at http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb I haven't paid much attention to llvmlinux for a whil...

On Wed, 2018-02-07 at 23:30 +0000, Chandler Carruth wrote: > This should go to llvm-commits as a proper review. Do you want to do > that David? Want someone on our end to pick it up? I'll attempt to add some test cases... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available

...-mtriple=i686-- -no-integrated-as | FileCheck > -check-prefix=X86 %s > ; RUN: llc < %s -mtriple=x86_64-- -no-integrated-as | FileCheck > -check-prefix=X64 %s > > ; If the target does not have 64-bit integer registers, emit 32-bit > register > ; names. > > ; X86: calll __x86_indirect_thunk_e{{[abcd]}}x > ; X64: callq __x86_indirect_thunk_r > > define void @q_modifier(i32* %p) { > entry: > tail call void asm sideeffect "call __x86_indirect_thunk_${0:V}", > "r,~{dirflag},~{fpsr},~{flags}"(i32* %p) > ret void > } -------------- next part --...

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

...s ABI however it wants. For our other users, they specifically don't want this in the ABI (because they actually have DSOs and other junk being linked together). And yes, we actually have a decent number of users of this in userspace and outside the kernel. =/ > > > You can even use __x86_indirect_thunk_\reg for *now* and reserve the > right to use a different name if you ever do revise the ABI. > > > Maybe I don't understand, but I'm surprised that there is a significant > burden to having aliases for now instead? > > > You can make that work within the kernel image...

...0, David Woodhouse wrote: > > > Hm, please could we also have the %V asm constraint modifier? That > > > allows us to emit calls to the thunks from inline asm using the > > > register that the compiler chose for us: > > > > > >  asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : : > > > [thunk_target] "r" (the_function));  > > > > > > Other than that, I get the following errors with LLVM+Clang master, and > > > my tree at > > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog...