<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <<a href="mailto:dwmw2@infradead.org">dwmw2@infradead.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote:<br>
><br>
> Two aspects to this...<br>
><br>
> One, we're somewhat reluctant to guarantee an ABI here. At least I<br>
> am. While we don't *expect* rampant divergence here, I don't want<br>
> this to become something we cannot change if there are good reasons<br>
> to do so. We've already changed the thunks once based on feedback<br>
> (putting LFENCE after the PAUSE).<br>
<br>
Surely adding the lfence was changing your implementation, not the ABI?<br>
<br>
And if we really are talking about the *ABI* not the implementation,<br>
I'm not sure I understand your concern.<br>
<br>
The ABI for each thunk is that it is identical in all respects, apart<br>
from speculation, to 'jump *\reg'. There's not a lot of scope for a<br>
'v2' of that, surely?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I could live with the command-line divergence, although it's<br>
suboptimal. But *please* since these things also need to be symbols<br>
exported to loadable modules, can't we keep the thunk names identical?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>While you *can* export your external thunk, that's a choice of the code defining the thunk.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can even use __x86_indirect_thunk_\reg for *now* and reserve the<br>
right to use a different name if you ever do revise the ABI.<br></blockquote><div><br></div><div>Maybe I don't understand, but I'm surprised that there is a significant burden to having aliases for now instead? <br></div></div></div>