search for: dprotivenski

Displaying 8 results from an estimated 8 matches for "dprotivenski".

Did you mean: dprotivensky
2015 Feb 25
2
[LLVMdev] [lld] Undefined symbols postprocessing
Okay, I understood that you're proposing to add all undefined symbols during the resolution step, and not try to collect extra symbols during execution and then check if some undefines left (as I originally planned). This sounds reasonable as in any case we must have all undefines resolved in order to continue the linking process. Concerning the implementation, why not to add this virtual
2015 Feb 23
2
[LLVMdev] [lld] Undefined symbols postprocessing
On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky <dprotivensky at accesssoftek.com> wrote: > Shankar, > > Okay, I guessed the correct interface. > But what about the moment at which the function is called? > If it's called from Resolver::resolve(), it doesn't make any difference to > me as I cannot determine the need of specific symbols at that time. > > -
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
2015 Feb 09
2
[LLVMdev] [lld] Representation of lld::Reference with a fake target
Hi, The round trip passes just tries to load a *complete* object file in YAML/Native format back. The internal state should be the complete object file in native/yaml format. If some state is not recorded and that is really needed in the writer, we should add that to the Atom model. Shankar Easwaran On 2/9/2015 1:29 PM, Rui Ueyama wrote: > I want to bring this again because I think
2015 Feb 09
2
[LLVMdev] [lld] Representation of lld::Reference with a fake target
A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation. Concerning native format: it also introduced unneeded code complexity to me when I wanted to set calculated relocation addend back into the Reference object in the
2015 Feb 19
4
[LLVMdev] [lld] Undefined symbols postprocessing
+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote: > On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or
2015 Feb 19
3
[LLVMdev] [lld] Undefined symbols postprocessing
Joerg: > I propose to add the ability to ignore undefined symbols during initial > resolution, and then postprocess only those undefines for the second time > after the pass manager execution. Do you want to do that before or after dead code elimination? I think dead code elimination should be performed after all possible object code modifications done by lld. Therefore, it should be
2015 Jan 12
2
[LLVMdev] [lld] ARM/Thumb atom forming
Thanks, Shankar. I needed to override all the places where st_value had been used, and it worked. But there another problem appeared: after correcting all atoms, I cannot distinguish between ARM and Thumb symbols in the further stages when fixing up relocations. I used to check targetVAddress (in terms of the relocation handler) since it contained 1 in the least bit when addressing Thumb