<html><head></head><body><div><br></div><div class="-x-evo-paragraph -x-evo-top-signature-spacer"><br></div><div>On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote:</div><blockquote type="cite"><div dir="ltr"><div>So, I was waiting to hear a definitive response on whether using aliases is hard, and didn't see one here, which is why I haven't responded further.</div><div><br></div><div>However, a colleauge pointed me at an LKML thread where it seems there *is* a definitive response?</div></div></blockquote><div><br></div><div>Aliases are hard when the compiler is directly emitting calls to a function which is exported to modules, yet the compiler and the kernel disagree on what the symbol is actually called.</div><div><br></div><div>I spent a happy Sunday evening in a hotel room a few weeks ago, trying to make them work before telling the GCC folk "screw it this is too horrible please keep the symbol name as it is".</div><div><br></div><div>If I was insufficiently definitive, that's because I was inviting someone to prove me wrong — which I was still doing in the LKML thread you saw.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div>I'm really looking for clear direction: we can try to implement custom naming, but it will add undesirable complexity to the compiler. Do we need it for the kernel? I have to ask because I genuinely don't know what is or isn't reasonable in the kernel.</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Feb 3, 2018 at 6:36 AM David Woodhouse <<a href="mailto:dwmw2@infradead.org">dwmw2@infradead.org</a>> wrote:<br></div><blockquote type="cite">It's *only* the external thunk where it absolutely<br>
*does* become an ABI, where we care about consistency.<br></blockquote><div><br></div><div>In the future, if there is such a powerful need for consistency, it would be good to actually engage with more than one compiler community. =/ As I said, I tried to talk to the GCC developers and made no progress but also heard no strong arguments that this kind of consistency was actually necessary.</div></div></div></blockquote><div><br></div><div>Yes, it would be good to engage with more than one compiler community. In the grand scheme of things that's probably one of the *smaller* things that didn't get handled right during this whole fiasco.</div><div><br></div><div>You'll note that when I added 16-bit support to LLVM/clang, I *did* make sure we did things consistently, and now the kernel boot code builds with -m16 with both clang and GCC.</div><div>On this occasion, I didn't get that right. I could have turned up here sooner after the embargo was broken. I take responsibility for that delay; I'm sorry.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>I really do want to produce a feature that addresses the kernel's needs, but we need to know what they are and have some chance to figure out how to find a solution that also doesn't cause problems for the compiler. This is just a note for the future though, the retpoline stuff is above.</div></div></div>
</blockquote><div><br></div><div>At this point, what we really want is for identical thunks to have identical names — just like we do for builtins and other stuff, to avoid having differences between clang and GCC which just end up seeming capricious and being hard to work around. Having matching command line options would be a bonus, but isn't imperative.</div><div><br></div><div>If you reserve the right to invent new thunk ABIs later and thus have different names for those, that's absolutely fine. You'd break our build if you added those unconditionally anyway; we can choose to support them or not. And hopefully if GCC did the same, then again the thunk symbols would match.</div></body></html>