search for: stt_common

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

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

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

...ion, /// .type _foo, STT_FUNC # aka @function - MCSA_ELF_TypeIndFunction, /// .type _foo, STT_GNU_IFUNC - MCSA_ELF_TypeObject, /// .type _foo, STT_OBJECT # aka @object - MCSA_ELF_TypeTLS, /// .type _foo, STT_TLS # aka @tls_object - MCSA_ELF_TypeCommon, /// .type _foo, STT_COMMON # aka @common - MCSA_ELF_TypeNoType, /// .type _foo, STT_NOTYPE # aka @notype - MCSA_Global, /// .globl - MCSA_Hidden, /// .hidden (ELF) - MCSA_IndirectSymbol, /// .indirect_symbol (MachO) - MCSA_Internal, /// .internal (ELF) - MCSA_LazyReferen...

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

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

...-specific */ + +#define STT_NOTYPE 0 /* symbol type is unspecified */ +#define STT_OBJECT 1 /* symbol is a data object */ +#define STT_FUNC 2 /* symbol is a code object */ +#define STT_SECTION 3 /* symbol associated with a section */ +#define STT_FILE 4 /* symbol's name is file name */ +#define STT_COMMON 5 /* symbol is a common data object */ +#define STT_TLS 6 /* symbol is thread-local data object*/ +#define STT_NUM 7 /* number of defined types. */ +#define STT_LOOS 10 /* start of OS-specific */ +#define STT_HIOS 12 /* end of OS-specific */ +#define STT_LOPROC 13 /* start of processor-specific...