search for: sharedlibraryatom

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

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

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

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

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

On Sep 24, 2013, at 9:13 AM, Joerg Sonnenberger wrote: > On Tue, Sep 24, 2013 at 10:49:36AM -0500, Shankar Easwaran wrote: >> Not sure why this is being done for a long time with the GNU linker. > > Because the main program is not PIC, it will only use absolute > references to global symbols. For functions, you can create a PLT > record, but for data access, you have to hide

On Tue, Sep 24, 2013 at 10:49:36AM -0500, Shankar Easwaran wrote: > Not sure why this is being done for a long time with the GNU linker. Because the main program is not PIC, it will only use absolute references to global symbols. For functions, you can create a PLT record, but for data access, you have to hide the real symbol and copy the content over to the equivalent in the main binary.

...is the IAT not just constructed in the PECOFF Writer? Why does it need >> to be an Atom? What relocations need to point to it? If they are relocations >> created by the Writer, you are fine. If you mean that other atoms may >> have References (in)to the IAT, then that is what SharedLibraryAtoms are >> for. They are place holders that expand to something real in the Writer. >> >> Mach-o has all kinds of crazy data structures that are constructed in the Writer. >> This is different than Darwin ld64 where the Writer actually created atoms for >> its data s...

I've run into some issues with the current atom object model that I would like to fix. The current 4 atoms are not expressive enough. We need to be able to serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

Hi all, I've been thinking about how best to represent MachO's LC_REEXPORT_DYLIB (used even by libSystem.dylib to provide its various sub-components[*]). It looks like this functionality would naturally fall into the InputGraph, in analogy with Groups and Archives. Unfortunately, it's rather more dynamic than the existing cases: we don't know the needed files before parsing the