llvm dev - Mar 2016 - RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR

> On Mar 11, 2016, at 11:26 AM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> Now, there are a number of things about linkage that are kindof
orthogonal,
>> and it would be nice to model them more orthogonally.  That would be a
major
>> change in representation, though.  Absent the will to do that, I
propose
>> that we:
>>  - remove/deprecate protected visibility, making visibility purely a
hidden
>> vs. non-hidden flag
> 
> This would prevent us from propagating
> __attribute__((visibility("protected")) to a STV_PROTECTED in the
.o,
> so I don't think we should do it.
The whole point of this proposal is to get us to a state where we can use
STV_PROTECTED for ordinary external or weak_for_linker symbols.

__attribute__((visibility(“protected”))) on a strong definition would just map
to ordinary non-hidden external linkage, which the backend would turn into
STV_PROTECTED.

__attribute__((visibility(“default”))) on a strong definition would map the
same way unless -fsemantic-interposition was enabled.

The point of removing protected visibility is that we don’t actually honor
default visibility in the ELF sense, so it’s silly to pretend that LLVM
visibility is the same as ELF visibility.  ELF protected visibility is basically
the semantics LLVM already assigns to default visibility.
>>  - add weak_for_linker, weak_odr_for_linker, linkonce_for_linker, and
>> linkonce_odr_for_linker (better names highly desired) to model the
>> weak-with-protected-visibility cases
>>  - add strong_for_linker (better name highly desired) to model the
>> strong-but-interposable case
> 
> For representing interposition we would only need one extra linkage
> type: interposable (runtime_weak?).
The other linkages are an attempt to preserve the ability to use STV_PROTECTED
on weak definitions while eliminating protected visibility from LLVM.
> We could split the linkage into multiple orthogonal bits, like: odr,
weak_for_linker,
> weak_for_runtime, can_be_dropped_if_unused, etc, but I think that is
> an independent cleanup
I agree that that would be best done independently.

John.

On 11 March 2016 at 14:58, John McCall <rjmccall at apple.com>
wrote:
>> On Mar 11, 2016, at 11:26 AM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>>> Now, there are a number of things about linkage that are kindof
orthogonal,
>>> and it would be nice to model them more orthogonally.  That would
be a major
>>> change in representation, though.  Absent the will to do that, I
propose
>>> that we:
>>>  - remove/deprecate protected visibility, making visibility purely
a hidden
>>> vs. non-hidden flag
>>
>> This would prevent us from propagating
>> __attribute__((visibility("protected")) to a STV_PROTECTED in
the .o,
>> so I don't think we should do it.
>
> The whole point of this proposal is to get us to a state where we can use
> STV_PROTECTED for ordinary external or weak_for_linker symbols.
And you can't also just produce STV_PROTECTED for every symbol. I
would love for that to be the case, but while most ELF systems support
copy relocations and related PLT hacks for functions it is not
practical to do it.
> __attribute__((visibility(“protected”))) on a strong definition would just
map
> to ordinary non-hidden external linkage, which the backend would turn into
> STV_PROTECTED.
>
> __attribute__((visibility(“default”))) on a strong definition would map the
> same way unless -fsemantic-interposition was enabled.
>
> The point of removing protected visibility is that we don’t actually honor
> default visibility in the ELF sense, so it’s silly to pretend that LLVM
> visibility is the same as ELF visibility.  ELF protected visibility is
basically
> the semantics LLVM already assigns to default visibility.
Except that we still produce STV_DEFAULT. Basically we have a mode
where we handle GVs as if they were protected but produce a
STV_DEFAULT.

If we are going to drop it, I think the only workable default solution
would be for -fsemantic-interposition to be the default. That is, on
ELF systems we would match GCC: with -fPIC we don't inline non-odr
symbols that end up as STV_DEFAULT.

In summary, I think it is important that

* a __attribute__((visibility("protected"))) maps to STV_PROTECED
* by default a decl with no attributes maps to STV_DEFAULT

Cheers,
Rafael

> On Mar 11, 2016, at 12:16 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> On 11 March 2016 at 14:58, John McCall <rjmccall at apple.com> wrote:
>>> On Mar 11, 2016, at 11:26 AM, Rafael Espíndola <rafael.espindola
at gmail.com> wrote:
>>>> Now, there are a number of things about linkage that are kindof
orthogonal,
>>>> and it would be nice to model them more orthogonally.  That
would be a major
>>>> change in representation, though.  Absent the will to do that,
I propose
>>>> that we:
>>>> - remove/deprecate protected visibility, making visibility
purely a hidden
>>>> vs. non-hidden flag
>>> 
>>> This would prevent us from propagating
>>> __attribute__((visibility("protected")) to a
STV_PROTECTED in the .o,
>>> so I don't think we should do it.
>> 
>> The whole point of this proposal is to get us to a state where we can
use
>> STV_PROTECTED for ordinary external or weak_for_linker symbols.
> 
> And you can't also just produce STV_PROTECTED for every symbol. I
> would love for that to be the case, but while most ELF systems support
> copy relocations and related PLT hacks for functions it is not
> practical to do it.
I’m sorry, I'm not familiar with the technical problems here.

For example, I don’t understand why protected symbols require new relocations.
I would expect that, as far as relocations go, they would be treated the same as
hidden symbols within the linkage unit, and the same as default symbols outside
of it.
>> __attribute__((visibility(“protected”))) on a strong definition would
just map
>> to ordinary non-hidden external linkage, which the backend would turn
into
>> STV_PROTECTED.
>> 
>> __attribute__((visibility(“default”))) on a strong definition would map
the
>> same way unless -fsemantic-interposition was enabled.
>> 
>> The point of removing protected visibility is that we don’t actually
honor
>> default visibility in the ELF sense, so it’s silly to pretend that LLVM
>> visibility is the same as ELF visibility.  ELF protected visibility is
basically
>> the semantics LLVM already assigns to default visibility.
> 
> Except that we still produce STV_DEFAULT. Basically we have a mode
> where we handle GVs as if they were protected but produce a
> STV_DEFAULT.
Yes, I don’t think this is a justifiable position.  We either do or do not
support
interposition of global definitions.
> If we are going to drop it, I think the only workable default solution
> would be for -fsemantic-interposition to be the default. That is, on
> ELF systems we would match GCC: with -fPIC we don't inline non-odr
> symbols that end up as STV_DEFAULT.
> 
> In summary, I think it is important that
> 
> * a __attribute__((visibility("protected"))) maps to STV_PROTECED
> * by default a decl with no attributes maps to STV_DEFAULT
It’s not really my place to decide whether or not -fsemantic-interposition
should be
the default, so I’ll leave this up to others to debate.

My instinct is that interposition is not actually important to very many people,
and that the people who rely on it won’t really mind having to opt in.  We have
also been optimizing as if semantic interposition were disabled for many years,
and I don’t remember hearing widespread complaints about it.  So I would
encourage us to turn it off by default, despite not matching GCC.  But like I
said, that is not ultimately my call, and I’ll leave the decision to others.

John.