[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Mon May 9 15:49:09 PDT 2016


> I am assuming "preemtable" means that a preemtable symbol can be rewritten by the dynamic loader to refer to something other than the locally available definition. We should standardize on this term (or "interposable" which I like), but calling this kind of thing a "weak" symbol confuses me.

I like interposable too. Thanks.


> ---
>
> Both preemtable and extern_local sound like great ideas, but how should we tell the compiler to generate copy relocations for a declaration of a GV?

That is extern_local. That tells llc to assume the symbol is local.
Not from the example that it produces "leaq a(%rip), %rax", which will
create a copy relocation is the assumption in wrong.

> It seems to me that copy relocation generation is really only safe if you know something about the way that the current TU is going to be linked: i.e. it's going into the executable and the linker supports copy relocations.

and the DSO that defines is is ready for it being preempted.

But not that copy relocation is one way of handling an extern_local.
The other one is just resolving the relocation in the the definition
ends up really being in the current DSO.

> Those seem like properties of the module to me, which is why we were going with module flags. We can invent a new linkage for this instead. Maybe call it `extern_copy`. When using appropriate flags, clang could apply it to all GV declarations. Do people like this better?

See above why I don't think we need a copy linkage.

> It also allows the user to avoid generating copy relocations against certain GVs that might change size. The fact that the size of a GV is part of its ABI in ELF was personally very surprising to me:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
> https://github.com/google/sanitizers/issues/619

Yes. That is why I suggested having dllimport control this on a decl
by decl basis. By default you get extern_local which can result in a
copy relocation. If you don't want that for 'foo', you can get an
extern by marking it dllimport.

Cheers,
Rafael


More information about the llvm-commits mailing list