[LLVMdev] [lld] ELF needs type for SharedLibraryAtom.

Shankar Easwaran shankare at codeaurora.org
Tue Sep 24 11:35:14 PDT 2013

On 9/24/2013 1:16 PM, Nick Kledzik wrote:
> On Sep 24, 2013, at 9:13 AM, Joerg Sonnenberger wrote:
>> On Tue, Sep 24, 2013 at 10:49:36AM -0500, Shankar Easwaran wrote:
>>> Not sure why this is being done for a long time with the GNU linker.
>> Because the main program is not PIC, it will only use absolute
>> references to global symbols. For functions, you can create a PLT
>> record, but for data access, you have to hide the real symbol and copy
>> the content over to the equivalent in the main binary.
> On Darwin, non-PIC programs use runtime text-relocations.  The loader modifies the instructions (which are referencing absolute addresses) to reference the right runtime address (in some shared library).
> How can copying data work?  If a program references data in a shared library, and you copy the data into the program, you now have two copies of the data and their content can diverge.
Yes it does get a  copy of the data in the main program. What the main 
program does is it exports its definition so that the runtime resolver 
will resolve against the copied data. So essentially at runtime even if 
you have two copies of the data, the dynamic library still refers to the 
program's copy.

> Is this "missing-copy-relocation" a build time or runtime relocation?  That is, does the static linker copy the data content? or the runtime loader (ld.so)?

Few ELF linkers perform the optimization at static linktime to avoid 
runtime copies. The GNU linker by default just reserves the size in the 
bss section and the runtime linker copies the data.

So the runtime relocation would have R_*_GLOB_DAT instead of R_*_COPY.


Shankar Easwaran

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

More information about the llvm-dev mailing list