[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 18:34, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Fri, Mar 11, 2016 at 01:54:36PM -0800, John McCall via cfe-dev wrote:
>> I’m sorry, but I didn’t quite get that.  The symbol is defined as protected
>> by the dynamic library, but the main executable can’t just use an ordinary
>> external symbol reference to it for some reason?
>
> The main program is not position independent. A function call is fine,
> the linker will provide a PLT slot for that and the issue is done. The
> problems are accessing a variable OR taking the pointer of a function.
> With non-PIC code on x86, you get an immediate load. But the linker
> can't adjust this into a load from the GOT.

Yes. There is quite a bit of confusion about protected being "you get
something semantically equivalent" or "you get exactly this entry".
With the first interpretation you cannot assume the address, with the
second one you can. See
https://sourceware.org/bugzilla/show_bug.cgi?id=19823 for example.

But this is getting into a bit more detail than what we need. The
sufficient summary is that STV_PROTECTED is sufficiently broken that
we probably cannot make it the default.

IMHO we can do the same as gcc: default visibility can be preempted
and is not inlined with -fPIC. Use -fvisibility=protected if you want
inlining and handle whatever brokenness you find in the system tools.

But that is a pretty big change. I would ask that if you want to make
that change, please start a thread in llvmdev to see what others
think. I wouldn't even mention IR changes. For now, lets just focus at
the end to end (C to .o) difference.

Cheers,
Rafael