Displaying 3 results from an estimated 3 matches for "stv_protec".
Did you mean:
stv_proteced
2016 Mar 11
3
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...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 eve...
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...sentation, 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...
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
> On Mar 11, 2016, at 1:40 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>> 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...