Michael Spencer
2013-Sep-23 23:52 UTC
[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: <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
Shankar Easwaran
2013-Sep-24 02:05 UTC
[LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
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
Joerg Sonnenberger
2013-Sep-24 07:10 UTC
[LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
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
Seemingly Similar Threads
- [LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
- [LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
- [LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
- [LLVMdev] [lld] ELF needs type for SharedLibraryAtom.
- [LLVMdev] [lld] Atom object model refactoring.