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

[Nick Kledzik]

On Sep 23, 2013, at 7: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.
> 
> This is needed for TLS. A undefined symbol could be set to TLS, so that symbols are resolved with the same type.
Yes.

>> 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 ?
I think you are confusing the two overloaded uses of "weak". canBeNullAtRuntime is for "weak imports" (can be missing at runtime).  "Weak definitions" are used with C++ (can be multiple at runtime).  For instance operator new in libc++.dylib is a weak definition.  A program which defines its own (non-weak) operator new, will override the one in libc++.dylib. 

-Nick