[llvm-dev] retpoline mitigation and 6.0
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 2 16:51:59 PST 2018
On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote:
> >
> > Two aspects to this...
> >
> > One, we're somewhat reluctant to guarantee an ABI here. At least I
> > am. While we don't *expect* rampant divergence here, I don't want
> > this to become something we cannot change if there are good reasons
> > to do so. We've already changed the thunks once based on feedback
> > (putting LFENCE after the PAUSE).
>
> Surely adding the lfence was changing your implementation, not the ABI?
>
> And if we really are talking about the *ABI* not the implementation,
> I'm not sure I understand your concern.
>
> The ABI for each thunk is that it is identical in all respects, apart
> from speculation, to 'jump *\reg'. There's not a lot of scope for a
> 'v2' of that, surely?
>
While I hope we have converged and never need to chaneg them, when we
started, there was actually a substantially different ABI proposed, and
multiple different ones. So some changes already were needed.
We already have at least one change that has been proposed, but we haven't
decided to pursue yet: a thunk which includes the *load* of the address,
and specifically a collection to handle common repeated patterns of loads
that before retpoline would have folded into addressing modes. And these
would definitely have a different ABI.
>
> 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?
>
At least for LLVM when not using *external* thunks, we specifically *do not
export* the symbol. As a consequence, 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180203/26baaa32/attachment.html>
More information about the llvm-dev
mailing list