<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 2, 2018 at 4:59 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"><div><div><br></div><div class="m_-6931573958615490378-x-evo-paragraph m_-6931573958615490378-x-evo-top-signature-spacer"><br></div><div>On Sat, 2018-02-03 at 00:51 +0000, Chandler Carruth wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>While you *can* export your external thunk, that's a choice of the code defining the thunk.</div></div></div></blockquote><div><br></div></div><div><div>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.</div></div></blockquote><div><br></div><div>Sure, I can see why for the kernel, this is important. It also gets to essentially define its ABI however it wants.</div><div><br></div><div>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. =/</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote type="cite">
<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>
</blockquote><div><br></div></div><div><div>You can make that work within the kernel image itself, and export only the existing names. It gets somewhat harder to support loadable modules which attempt to use the thunks by different names to the function that's exported. I'm not sure how we'd hack up the unresolved symbols in the module objects to match the exported symbol names.</div></div></blockquote><div><br></div><div>I had actually wanted to originally have the '-mretpoline-external-thunk' flag take a completely custom name for the thunks on the command line. Unfortunately, that proved remarkably annoying to implement in LLVM (for pretty silly reasons, but it is what it is). I didn't do that in large part because it seemed easy for users of external thunks to alias things themselves.</div><div><br></div><div>If the way loadable modules in the kernel work actually makes that quite hard, we can look again at allowing the external thunks to have a user controlled name. This seems strictly superior to any kind of agreed-to naming scheme as it gives you much more control. But it'll be really messy in LLVM to do[1], so I'd appreciate understanding how important this is for the kernel.</div><div><br></div><div>-Chandler</div><div><br></div><div>[1]: Yeah, it really shouldn't be. We are aware that this is a nasty aspect to how various components of LLVM are wired together and want to have better infrastructure here. But today, we don't. And especially since all of this needs to be backported to old versions of Clang and LLVM, we can't fix that and instead need to work around the existing infrastructure.</div></div></div>