[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote:
> 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.
> 
> However, a colleauge pointed me at an LKML thread where it seems
> there *is* a definitive response?
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.
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".
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.
> 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.

> On Sat, Feb 3, 2018 at 6:36 AM David Woodhouse <dwmw2 at infradead.org> wrote:> > It's *only* the external thunk where it absolutely
> > 
> > *does* become an ABI, where we care about consistency.> > 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.
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.
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.
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.
> 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.
> 

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/c2c36806/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/c2c36806/attachment.bin>