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
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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
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 Tue, Oct 22, 2013 at 12:16 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Its a DefinedAtom whose value is set by the Target Handlers. > > On 10/21/2013 3:08 PM, Simon Atanasyan wrote: >> 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.-- Simon
Possibly Parallel Threads
- [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol
- [LLVMdev] [lld] Handle _GLOBAL_OFFSET_TABLE symbol
- [LLVMdev] LLVMdev Digest, Vol 112, Issue 56
- [LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file
- [LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file