[LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
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
> 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.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
More information about the llvm-dev