Displaying 5 results from an estimated 5 matches for "mcarmelcstream".
Did you mean:
mcarmelcstreamer
2012 Oct 07
0
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
...ent code (Thumb/Arm) and the latter restoring it, by
emiting the $d and $a/t respectively.
Does it seem like a good initial approach?
Continuing... It seems MCELFStreamer already has a EmitThumbFunc,
which looks to me as the wrong place to be. I'd imagine MCELFStreamer
would have EmitFunc and MCARMELCStreamer (or whatever) would identify
its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
pedantic, even that is still too high level because of the ARM/Thumb
veneers, but we don't want to worry about that if LLVM doesn't even
try to mix ARM and Thumb (and assuming external librarie...
2012 Oct 09
2
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
.... It seems MCELFStreamer already has a EmitThumbFunc,
> which looks to me as the wrong place to be.
That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function.
> I'd imagine MCELFStreamer
> would have EmitFunc and MCARMELCStreamer (or whatever) would identify
> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
> pedantic, even that is still too high level because of the ARM/Thumb
> veneers, but we don't want to worry about that if LLVM doesn't even
> try to mix ARM and Thumb (and assumi...
2012 Oct 05
2
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> Hi Greg,
>
>> Is this a bug? If so, how can I fix it?
>
> It's somewhere between a bug and a quality-of-implementation issue.
> ARM often uses literal pools in the middle of code when it needs to
> materialize a large constant (or variable address more likely for
>
2012 Oct 10
0
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
...already has a EmitThumbFunc,
>> which looks to me as the wrong place to be.
>
> That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function.
>
>> I'd imagine MCELFStreamer
>> would have EmitFunc and MCARMELCStreamer (or whatever) would identify
>> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
>> pedantic, even that is still too high level because of the ARM/Thumb
>> veneers, but we don't want to worry about that if LLVM doesn't even
>> try to mix ARM and T...
2012 Oct 10
2
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
...c,
>>> which looks to me as the wrong place to be.
>>
>> That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function.
>>
>>> I'd imagine MCELFStreamer
>>> would have EmitFunc and MCARMELCStreamer (or whatever) would identify
>>> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
>>> pedantic, even that is still too high level because of the ARM/Thumb
>>> veneers, but we don't want to worry about that if LLVM doesn't even
>>> try...