Displaying 4 results from an estimated 4 matches for "weak_for_link".
Did you mean:
weak_for_linker
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...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
- 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
John.
-------------- next part --------------
An...
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...en 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...
2016 Mar 11
4
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
> On Mar 11, 2016, at 8:33 AM, Reid Kleckner <rnk at google.com> wrote:
> On Thu, Mar 10, 2016 at 10:32 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions
2016 Mar 11
3
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...om 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...