llvm dev - Sep 2013 - [LLVMdev] [lld] ELF needs type for SharedLibraryAtom.

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.

Joerg

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.

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)?

-Nick

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