
<html><head></head><body><div><br></div><div class="-x-evo-paragraph -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>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><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>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></body></html>