search for: addatom

Displaying 6 results from an estimated 6 matches for "addatom".

Did you mean: adadom
2013 Oct 21
1
[LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol
The Hexagon target adds new atom using the addAbsoluteAtom() functions and then assigns a virtual address in the finalizeSymbolValues() routine. The X86_64 target uses addAtom() function to add an object of the GLOBAL_OFFSET_TABLEAtom class to do the same thing. What is the reason of this difference? Is the GLOBAL_OFFSET_TABLEAtom just a useful wrapper which eliminates the necessity to assign an address to the atom explicitly in the finalizeSymbolValues() routine? On Tu...
2013 Oct 21
2
[LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol
Hi, What is a recommended way of handling (define, assign value) _GLOBAL_OFFSET_TABLE symbol? It looks like Hexagon and X86_64 targets use different API to achieve the same result. tia, Simon
2013 Oct 21
0
[LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol
Its a DefinedAtom whose value is set by the Target Handlers. On 10/21/2013 3:08 PM, Simon Atanasyan wrote: > Hi, > > What is a recommended way of handling (define, assign value) > _GLOBAL_OFFSET_TABLE symbol? It looks like Hexagon and X86_64 targets > use different API to achieve the same result. > > tia, > > Simon > _______________________________________________
2014 Mar 14
4
[LLVMdev] Is lld the linker we need for our project ?
Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is
2013 Oct 21
0
[LLVMdev] LLVMdev Digest, Vol 112, Issue 56
...sage-ID:     <CAGyS+DSCbWZEfuWONXqnuLxvDEsLbdM=i=UL8FKM+wdf9F-LHw at mail.gmail.com> Content-Type: text/plain; charset=UTF-8 The Hexagon target adds new atom using the addAbsoluteAtom() functions and then assigns a virtual address in the finalizeSymbolValues() routine. The X86_64 target uses addAtom() function to add an object of the GLOBAL_OFFSET_TABLEAtom class to do the same thing. What is the reason of this difference? Is the GLOBAL_OFFSET_TABLEAtom just a useful wrapper which eliminates the necessity to assign an address to the atom explicitly in the finalizeSymbolValues() routine? On Tu...
2015 Feb 18
6
[LLVMdev] [lld] Undefined symbols postprocessing
Hi everyone, In lld, I need to conditionally add symbols (like GLOBAL_OFFSET_TABLE) during static linking because they may be used by relocations (R_ARM_TLS_IE32) or by some other stuff like STT_GNU_IFUNC symbols. The problem is that now symbols are added in a declarative way by specifying in ExecutableWriter::addDefaultAtoms() override. At that stage, there's no way to determine if