search for: x86_64_reloc_branch

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

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

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

...that refers directly to the symbol if defined within the current module, or to a PLT entry if not. This is the same type of relocation that is needed to implement relative branches on x86, so I'd expect it to be generally available on that architecture (ELF has R_{386,X86_64}_PLT32, Mach-O has X86_64_RELOC_BRANCH, COFF has IMAGE_REL_{AMD64,I386}_REL32, which may resolve to a thunk [1], which is essentially the same thing as a PLT entry). It is also present on ARM (R_ARM_PREL31, which was apparently added to support unwind tables). > > We still need some way to create PLT relocations in the vtable'...

...y to the > symbol if defined within the current module, or to a PLT entry if not. This > is the same type of relocation that is needed to implement relative > branches on x86, so I'd expect it to be generally available on that > architecture (ELF has R_{386,X86_64}_PLT32, Mach-O has X86_64_RELOC_BRANCH, > COFF has IMAGE_REL_{AMD64,I386}_REL32, which may resolve to a thunk [1], > which is essentially the same thing as a PLT entry). It is also present on > ARM (R_ARM_PREL31, which was apparently added to support unwind tables). > > We still need some way to create PLT relocations in...

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

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

...that refers directly to the symbol if defined within the current module, or to a PLT entry if not. This is the same type of relocation that is needed to implement relative branches on x86, so I'd expect it to be generally available on that architecture (ELF has R_{386,X86_64}_PLT32, Mach-O has X86_64_RELOC_BRANCH, COFF has IMAGE_REL_{AMD64,I386}_REL32, which may resolve to a thunk [1], which is essentially the same thing as a PLT entry). It is also present on ARM (R_ARM_PREL31, which was apparently added to support unwind tables). >> >> We still need some way to create PLT relocations in the vt...

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing