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

[Rafael Espíndola via cfe-dev]

On 11 March 2016 at 12:41, John McCall via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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> 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 as a general exception.
>
>
> Given that LLVM does IPO (inlining, funcattrs) on symbols that can be
> interposed on ELF, we already don't support interposability very well:
> https://llvm.org/bugs/show_bug.cgi?id=23501
>
> Adding another exception for virtual functions, especially under an
> off-by-default flag, doesn't seem like a big deal.
>
>
> Okay, so, it sounds to me like LLVM basically treats strong definitions as
> protected, then.  Should we just formalize that?
>
> I guess the proposal here would be:
>   1. Remove protected visibility from LLVM.  (Or deprecate it as equivalent
> to default.)

I wouldn't go that far. At least no for now.

It is true that given llvm's view of what it can inline, producing ELF
files with protected visibility would seem reasonable. The problem is
that they don't work well in combination with copy relocations, so we
cannot just produce protected everywhere.

But, there are cases where they are useful, so we should be able to
propagate __attribute__((visibility,("protected"))) to the object
file.

Cheers,
Rafael