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

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.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130923/89eb337d/attachment.html>

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.

Also the mach-o linker will need to know if a SharedLibraryAtom is a
weak-definition or not.

-Nick

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

On Mon, Sep 23, 2013 at 04:52:16PM -0700, Michael Spencer
wrote:
> The following code currently links incorrectly when linking against a
> dynamic libc on Ubuntu 12.10 unless -fpic is specified.
Isn't this the missing-copy-relocation item?

Joerg