search for: weak_for_link

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...