search for: undefinedatom

...r resolverState Context(nextFile) -------------- ------------------ ---------------- resolverState = initialState nextFile(resolverState) initialState ELFContextState=processingFileNode, return a.o resolverState = nochange process(a.o) state = definedatoms/undefinedatoms (reason: main/printf) nextFile(resolverState) definedAtoms/undefinedAtoms ELFContextState=processingFileNode, return b.o resolverState = nochange process(b.o) state = undefinedatoms(reason: pthread_create) nextFile(resolverState) undefinedAtoms ELFContextState=processingGroupNode, return libc.a...

...Resolver resolverState Context(nextFile) > -------------- ------------------ ---------------- > resolverState = initialState > nextFile(resolverState) initialState > ELFContextState=processingFileNode, return a.o > resolverState = nochange > process(a.o) > state = definedatoms/undefinedatoms (reason: main/printf) > nextFile(resolverState) definedAtoms/undefinedAtoms > ELFContextState=processingFileNode, return b.o > resolverState = nochange > process(b.o) > state = undefinedatoms(reason: pthread_create) > nextFile(resolverState) undefinedAtoms > ELFContextState=...

...cs.uiuc.edu Interesting feature. What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. Another approach is to use weak aliases. That is if a.o has an undefine for foo with a fallbac...

...> Interesting feature. > > What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. > > Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. > > Another approach is to use weak aliases. That is if a.o has an undefine for...

...YAML writer does not have anything to add here. >> >> The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options >> for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also may want to add extra linker internal files in the future. >> >> I prefer addImplicitFiles calling the reader to add more files, which means addFiles API moves to the reader. > But won’t that fail too if you were using a YAML Reader and ELF Writer? Yeah :( > Since...

...> The YAML writer does not have anything to add here. > > The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options > for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also may want to add extra linker internal files in the future. > > I prefer addImplicitFiles calling the reader to add more files, which means addFiles API moves to the reader. But won’t that fail too if you were using a YAML Reader and ELF Writer? Since we are talking about...

...o the YAML writer. The YAML writer doesnot have anything to add here. The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options for which it wants to create a DefinedAtom/UndefinedAtom. The flavor also may want to add extra linker internal files in the future. I prefer addImplicitFiles calling the reader to add more files, which means addFiles API moves to the reader. Thanks Shankar Easwaran On 8/28/2013 4:57 PM, Nick Kledzik wrote: > Shankar, > > The LinkingConte...

...xt(nextFile) >> -------------- ------------------ ---------------- >> resolverState = initialState >> nextFile(resolverState) initialState >> ELFContextState=processingFileNode, return a.o >> resolverState = nochange >> process(a.o) >> state = definedatoms/undefinedatoms (reason: main/printf) >> nextFile(resolverState) definedAtoms/undefinedAtoms >> ELFContextState=processingFileNode, return b.o >> resolverState = nochange >> process(b.o) >> state = undefinedatoms(reason: pthread_create) >> nextFile(resolverState) undefinedAtom...

...Interesting feature. >> >> What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. >> >> Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. >> >> Another approach is to use weak aliases. That is if a.o has...

The inverted dependency of Core to ReaderWriter via Simple.h was already present. My idea was to fix the problem before it gets bigger. My proposal would be to move Simple.h and Alias.h to Core. Similar to UndefinedAtom.h etc. It would be even nicer to make the naming consistent as well, since there already is UndefinedAtom.h SharedLibaryAtom.h etc Maybe: SimpleAtom.h AliasAtom.h Moving the file to core fixes the dependencies. On Mon, Jun 2, 2014 at 9:25 AM, Rui Ueyama <ruiu at google.com> wrote: >...

On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext,

Hi, Can we add deadStrip() to undefinedAtoms as well ? This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them. Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code...

...van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My idea was to fix the problem before it gets bigger. >> My proposal would be to move Simple.h and Alias.h to Core. Similar to >> UndefinedAtom.h etc. >> It would be even nicer to make the naming consistent as well, since there >> already is >> UndefinedAtom.h >> SharedLibaryAtom.h >> etc >> >> Maybe: >> SimpleAtom.h >> AliasAtom.h >> >> Moving the file to core fixes the dep...

...different kinds of Atoms. > No more, no less - matching the enum in Atom.h. > Is that correct? Stated that way, it makes the "four" seem arbitrary. It makes more sense once you see that the four kinds are: 1) DefinedAtom 95% of all atoms. This is a chunk of code or data 2) UndefinedAtom This is a place holder in object files for a reference to some atom outside the translation unit. During core linking it is usually replaced by (coalesced into) another Atom. 3) SharedLibraryAtom If a required symbol name turns out to be defined in a dynamic shared library (and not...

On Aug 28, 2013, at 4:24 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > >> Also for the case of -u, the Driver can make generic UndefinedAtoms. > ELF would want to treat the undefined symbols as a weak undefined symbols. So the driver cant create undefined atoms. > > Below is an example :- > > $cat 1.c > int _start() { return 0; } > $gcc -c 1.c > $ld -u myundef 1.o > ==> Does not throw any error, the reso...

...ting feature. >>> >>> What happens if a.o has an undefine foo which says its fallback is bar, but in b.o an undefine for foo says its fallback is baz? Is that an error, or does each fallback apply to its original usage. The problem is that the Resolver is currently coalescing UndefinedAtoms based on their name. I does not know that fallbacks need to match too. >>> >>> Another variant is to have Undefined return a alternate name as a string, rather than returning a new UndefinedAtom object. >>> >>> Another approach is to use weak aliases. Tha...

...er methods. >> We wouldnt be able to override the functionality with each flavor, if we have a static method, or you had thought of something else ? > I’m not sure when we would want polymorphism. If you wanted it in this case, there could be a method on LinkingContext to create a file of UndefinedAtoms, and ELFLinkingContext could override that method to make weak undefines. Yes this will work for undefined atoms that need to be supported by all flavors. All the implicit files that are needed would be added to a vector of files in the inputGraph, addImplicitFiles would splice/prepend to the li...

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

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

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