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

[Shankar Easwaran]

On 9/23/2013 9:05 PM, Shankar Easwaran wrote:
> On 9/23/2013 7:07 PM, Nick Kledzik wrote:
>> On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> 
>> wrote:
>>
>>> The following code currently links incorrectly when linking against 
>>> a dynamic libc on Ubuntu 12.10 unless -fpic is specified.
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>>    fputs("hi\n", stdout);
>>> }
>>>
>>> The reason is that stdout gets a R_X86_64_PC32 relocation, but is of 
>>> type Object. The ELF writer can't see this, and assumes all 
>>> R_X86_64_PC32 relocations in dynamic outputs are to functions and 
>>> thus need PLT entries. The correct behavior is to treat this as a 
>>> R_X86_64_GOTPCREL relocation. As this is what both gnu-ld and gold do.
>>>
>>> To handle this correctly we will need to add type information to 
>>> SharedLibraryAtom. We will also need to know about STT_COMMON in the 
>>> future.
>> Mach-o uses different relocations (X86_64_RELOC_BRANCH and 
>> X86_64_RELOC_SIGNED) to differentiate the two.
>>
>> I don’t think we need to copy the full ContentType from DefinedAtom.  
>> We just need to know if the DSO symbol is code or data.
> Since we are at it, we should add a type for undefinedAtoms too, not 
> sure what to call it.
Also the shared library atoms would need to have content(for data 
symbols), for the issue that Joerg brought. With GNU linkers, any 
external data reference from the executable thats resolved from a shared 
library, is copied into the main executable.

Not sure why this is being done for a long time with the GNU linker.

Thanks

Shankar Easwaran

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