Displaying 3 results from an estimated 3 matches for "strong_for_link".
Did you mean:
strong_for_linker
2016 Mar 11
2
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
- 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 HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160311/7d24ed3e/attachment.html>
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...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 definitio...
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