search for: definedatoms

...tion 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=processingGroupNode,...

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

...ecial handling for this, and the backend would just need to evaluate the expression at the end. Agreed. On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them DefinedAtoms of size zero, with a new ContentType that the ELF Writer knows does not need an address assigned. The References to each symbol used in its expression ensu...

...for this, and the backend would just need to evaluate the expression at the end. > Agreed. > > On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them DefinedAtoms of size zero, with a new ContentType that the ELF Writer knows does not need an address assigned. The References to each symbol used in its expression ensu...

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

...ard to use >> an existing type. There is a couple of ways to model this: 1) SHF_ALLOC=0 sections do not occupy space during execution, so they do not need addresses, so they are not atoms. Instead that section information is modeled as some kind of “attribute” (like a name or content type) of DefinedAtoms or the whole File. 2) If the dwarf can be parsed into chunks that can be associated with DefinedAtoms, then 2a) those chunks could be new attributes of an atom, or 2b) those chunks could be atoms themselves (with some defined way to set the name, permissions, etc of those new atoms) I have look...

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,

...d the backend would just need to evaluate the expression at the end. >> Agreed. >> >> On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them DefinedAtoms of size zero, with a new ContentType that the ELF Writer knows does not need an address assigned. The References to each symbol used in its expression ensu...

On Nov 11, 2014, at 11:54 AM, Rui Ueyama <ruiu at google.com> wrote: > This falls into the usual topic that whether or not we should have a generic map attached to an atom. You used a reference as an alternative for the map in this case but the basic idea is the same. > > Although using a reference would be practical, it still feels a hack to me. It's awkward at least. Why

...symbol size information that was present in the symbol table. >> b) A field in the DefinedAtom class to store the symbol size information (needed back for the NativeReader to construct the DefinedAtom object appropriately) >> >> Can I go ahead and do the modifications to the NativeDefinedAtomsIvarsV1 and the DefinedAtom class to store this additional attribute ? >> >> Thanks >> >> Shankar Easwaran >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation >> > > -- Qualcomm Innova...

...; currently don't have a type for this, and DefinedAtom.cpp makes assumptions > about the permissions of an Atom based on their type, so it's hard to use > an existing type. Can we parse the Debug sections into atoms too ? This way we could associate Debug information associated with DefinedAtoms (seperate reference types, probably). The advantage of this approach would be that Garbage collection would remove all the unneeded references automatically when the definedatom is removed. I think Nick also mentioned about a similiar way a while back. > The next problem is in the ELF writ...

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

...table. >>> b) A field in the DefinedAtom class to store the symbol size >>> information (needed back for the NativeReader to construct the >>> DefinedAtom object appropriately) >>> >>> Can I go ahead and do the modifications to the >>> NativeDefinedAtomsIvarsV1 and the DefinedAtom class to store this >>> additional attribute ? >>> >>> Thanks >>> >>> Shankar Easwaran >>> >>> -- >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>> hosted by the L...

Hi Nick, Thanks for your reply. On 8/23/2013 3:40 PM, Nick Kledzik wrote: > > These are the changes I plan to make, and some questions that I have > > a) Define a new contentType for DefinedAtoms to say 'Expression' > b) Create a new class ExprnAtom derived from DefinedAtom > c) The expression could also contain various functions that could be set in the expression, how should that be represented ? > I don’t understand this. I thought expression where like "_foo + 10”...

On Oct 30, 2012, at 3:48 PM, Shankar Easwaran wrote: > Hi Nick, > > Thanks for your reply. > > How about if the atom flags could be overridden ? The Atom flag could have a MIN/MAX and anything above the MAX or lower than the MIN are platform specific, like how its dealt with section indexes ? Can you be more specific in your proposal. What method(s) would you add to the the Atom

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

Hi Nick, Can we add a atomContentHash for DefinedAtoms when the atoms are being created. This can essentially speed up comparisons of atoms especially for * ICF (Identical code folding) * Section groups (to identify similiar sections) Not sure where else this would help. This would essentially be used only by the Reader and the Resolver. There wou...

I had a similar issue with arm vs thumb in mach-o. Each function’s thumbness is marked in its symbol table entry. But it is even worse, a function could change encoding in the middle (only hand coded assembly could do this). My solution was to add a new Reference Kind for mach-o which is the current instruction encoding. The offsetInAtom() is the offset where the encoding kind changes.

Hi Nick, Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots) 2) Or, uses a list of names that are dead strip roots (other types) Question:- *********** How are the dead strip root names supposed to be

Hi Nick, > Can you be more specific in your proposal. What method(s) would you add to the the Atom class(es)? I thought you were thinking of a generic uint32_t DefinedAtom::flags() method where the meaning of each bit in the uint32_t returned was platform specific. How can that work with a min/max range? > The range of flags would be integers ranging from LOW_PROC .. HIGH_PROC. The