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

[Shankar Easwaran]

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.

This is needed for TLS. A undefined symbol could be set to TLS, so that 
symbols are resolved with the same type.
> Also the mach-o linker will need to know if a SharedLibraryAtom is a weak-definition or not.
The SharedLibraryAtoms have a field canBeNullAtRuntime, could this be 
used for weak definitions ?

Thanks

Shankar Easwaran

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