llvm dev - Feb 2018 - retpoline mitigation and 6.0

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?

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/cb64b8d9/attachment.html>

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>

On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org>
wrote:
> 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".
>
Nah, this is plenty definitive for me. ;]

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.
>
After talking to several others (to make sure we don't have to do this
whole thing yet again) we'll change the external thunk names to match what
GCC is using. Hopefully this doesn't come back to bite us. =]

We'll also make sure those patches get backported too so that no released
versions have the old behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180207/07996e2b/attachment.html>