search for: definedatom

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

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

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

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

...xes >> 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 DefinedAtom.cpp makes assumptions >> about the permissions of an Atom based on their type, so it's hard 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. Instea...

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

...c 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 don't you add an accessor to the attribute you want to DefinedAtom? We'll have a few or maybe ten more member functions in DefinedAtom, but it's not bad -- architectures that don't need them are able to just not use them. And the number of attributes we want is limited because the number of architectures we want to support in LLD is not that many. If t...

...that was there >> in the symbol table needs to be preserved until the linker writes the binary. >> >> Referring to the above example we see that the function atom "foo", has contents set to >> >> jmp bar >> jmp foobar >> ret >> >> The definedAtom "foo" gets created with the above contents and sets the atom size to be the size of whatever data that has been read. In this example, the Atom size of "foo" becomes 5 bytes. >> But when the Atom "foo" gets written by the linker it needs to be set to the size tha...

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

...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 DefinedAtom.cpp makes assumptions about the permissions of an Atom based on their type, so it's hard to use an existing type. The next problem is in the ELF writer. It currently cannot handle AtomSections that are not in a segment as file offsets and addresses are never set. This means that assignOffsets...

...served until the linker writes >>> the binary. >>> >>> Referring to the above example we see that the function atom "foo", >>> has contents set to >>> >>> jmp bar >>> jmp foobar >>> ret >>> >>> The definedAtom "foo" gets created with the above contents and sets >>> the atom size to be the size of whatever data that has been read. In >>> this example, the Atom size of "foo" becomes 5 bytes. >>> But when the Atom "foo" gets written by the linker it...

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

...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 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? > >> I know ELF file format has some ranges for various values that are specifically reserved for processors or "user" defined functionality....

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

...tentType flags together with other > flags, it is pollute the common ELF code. If we factor out the > processing of MIPS specific flags, we have to duplicate code because a > symbol with say STO_MICROMIPS flag should be processed (setup size, > permissions etc) the same way as a regular DefinedAtom::typeCode > symbol. > > I considered to create a map symbol name => symbol flags, fill this > map while read object files, and use the map while write a linked > file. But I need to handle both local and global symbols and it is > possible to get symbols with the same name. &g...

...es (_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 set ? Does each Reader need to set specific information on what are the dead strip roots ? There is a flag in the DefinedAtom to determine whether to deadstrip an atom, deadStripNormal, deadStripAlways, deadStripNever Question :- ************ a) What is the difference between deadStripNormal/deadStripAlways ? b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but...

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 Generic flags would be within the range less than LOW_PROC and greater HIGH_PRO...