search for: sharedlibraryatoms

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

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

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

...d 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. Yes. >> 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 ? I think you are confusing the two overloaded uses of "weak". canBeNullAtRuntime is for "weak imports" (can be missing at runtime). "Weak definitions" are used with C++ (can be multiple at runti...

On 9/23/2013 9:05 PM, Shankar Easwaran wrote: > 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

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

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