search for: protivensky

Displaying 9 results from an estimated 9 matches for "protivensky".

2015 Feb 18
6
[LLVMdev] [lld] Undefined symbols postprocessing
...s to move from the declarative style towards imperative and more flexible approach. Of course, there's a downside as the code loses some of its regularity and becomes more volatile, but in the end - we have tests to cover such things and ensure everything works as expected. Any ideas? - Denis Protivensky.
2015 Feb 25
2
[LLVMdev] [lld] Undefined symbols postprocessing
...mbol handling for any 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...
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 ne...
2015 Jan 12
2
[LLVMdev] [lld] ARM/Thumb atom forming
...eeded. That's a lot of changes though, so I'd like to hear more thoughts. Regards, Denis. On 01/02/2015 09:32 PM, Shankar Easwaran wrote: You could just override symbolContentSize in the ARM Reader (remove the last bit to indicate thumb). Shankar Easwaran On 12/24/2014 3:09 AM, Denis Protivensky wrote: > Hi guys, > > I'm working on ARM architecture support for lld. > I faced the problem with ARM/Thumb symbols described below. > > ARM ELF Reference specifies that symbols addressing Thumb instructions > have zero bit of st_value field set (see 4.5.3). > General EL...
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 a...
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 Sep 07
2
POssible bug in the Arm code generator
Hi Erik, > GHC does not generate or use thumb instructions From you assembly dump, looks like the instructions are 2 bytes long, meaning it's Thumb code not ARM. - Denis. > Owen Shepherd wrote: > >> Pay closer attention to the instruction descriptions on the page you linked >> above: >> >> LDR{*type*}{*cond*}*Rt*, [*Rn* {, #*offset*}] ; immediate
2015 Feb 09
2
[LLVMdev] [lld] Representation of lld::Reference with a fake target
...robably want to teach 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 proces...
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