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