search for: dprotivensky

...cases other than static linking of the executable? - Denis. On 02/24/2015 06:44 AM, Nick Kledzik wrote: On Feb 23, 2015, at 2:52 PM, Michael Spencer <bigcheesegs at gmail.com><mailto:bigcheesegs at gmail.com> wrote: > On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky > <dprotivensky at accesssoftek.com><mailto: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...

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

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

...LLD about how to > emit a re-linkable object file in YAML or Native file. But the round-trip > tests do more than that, right? The tests require more -- dumping linker > internal state to a file and reading it correctly. > > On Mon, Feb 9, 2015 at 4:33 AM, Denis Protivensky < > dprotivensky at accesssoftek.com> wrote: > >> 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 applyR...

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

+ 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

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

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