search for: undefinedatoms

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

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

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

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

...of files to the vector of files and then process the InputFiles. > In the case of -u, it would be nice to group them all in one file named “command line option -u” so that any error messages about undefined symbols says the references was from “command line option -u” (as opposed to the -u UndefinedAtoms come from a generic internal file). Agree. > 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; }...

...mand line options, perhaps the Driver should be creating the files/atoms. In the case of -u, it would be nice to group them all in one file named “command line option -u” so that any error messages about undefined symbols says the references was from “command line option -u” (as opposed to the -u UndefinedAtoms come from a generic internal file). Also for the case of -u, the Driver can make generic UndefinedAtoms. Other options may need platform specific atoms which may be created with the help of static Writer methods. -Nick > On 8/28/2013 4:57 PM, Nick Kledzik wrote: >> Shankar, >>...

Hi Nick, The problem is when the -emit-yaml option is used, the writer is set to 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

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

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

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

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

On Mon, Jun 2, 2014 at 12:49 AM, Rui Ueyama <ruiu at google.com> wrote: > I agree to move these files to Core. Any objections? None here. - Michael Spencer > > On Mon, Jun 2, 2014 at 12:44 AM, Bas van den Berg > <b.van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> 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 >>>

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

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

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

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