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

[Shankar Easwaran]

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.

Thanks

Shankar Easwaran

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