search for: x86_64_reloc_signed

...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...

...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

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

Thank you for the explanation. Does that mean r_symbolnum is basically redundant in that case? Also, let me ask you how to handle the following use case which is somewhat related. Currently in MCJIT for MachO we are relocating all the debug sections. Eventually (as ELF does), it would be good to avoid this. However, this means that the debugger would have to handle relocations (as lldb currently

...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...

..._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 T...