llvm dev - Mar 2012 - [LLVMdev] Disassembly broken for thumb LDR

Hi all.

I'm investigating an issue with incorrect lldb's disassembly output. I
have two bytes in question: 4e5f

lldb (via the llvm's LLVMARMCodeGen) is providing the following mnemonics:

ldr    r6, #380,

However the value for ldr is "an 8-bit value that is multiplied by 4 and
added to the value of the PC to form the memory address" (via ARMARM), so
that the correct mnemonics is:

ldr     r6, [pc, #380]

(provided by Apple's otool).

I've traced the issue down to ARMInstrThumb.td:

// A8.6.57 & A8.6.60
defm tLDR  : thumb_ld_rr_ri_enc<0b100, 0b0110, t_addrmode_rrs4,
                                t_addrmode_is4, AddrModeT1_4,
                                IIC_iLoad_r, IIC_iLoad_i, "ldr",
                                UnOpFrag<(load node:$Src)>>;

In the generated TableGen output the issue lies around line 4992:

4992	    case ARM::tUXTH: printOperand(MI, 1, O); break;

As the operand is not enough in this case.

I'm pretty stuck at the TableGen deciphering to fix the issue. It'll be
nice if someone with more llvm skills would check the file and make the required
fix.

-- 
Vladimir Pouzanov
http://www.farcaller.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4454 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120326/02e45133/attachment.bin>

Hi Vladimir,

This is an artifact of the instruction printer. LLDB is decoding the instruction
correctly, but the normal printing of that instruction will be with a label
operand, not a raw immediate (like "ldr r6, Lmylabel"), so it's
taking the simplest output and just treating the immediate as if it were a
label. This works, but as you note, isn't very friendly. Better would be to
print "[pc, #imm]" for the operand. Testcases would need written and
some existing probably need updated to match. The parser should already handle
the new form, but that would need to be validated, of course.

A patch to fix this would be great, but in the absence of that, please file a
PR.

-Jim


On Mar 26, 2012, at 3:39 AM, Vladimir Pouzanov <farcaller at gmail.com>
wrote:
> Hi all.
> 
> I'm investigating an issue with incorrect lldb's disassembly
output. I have two bytes in question: 4e5f
> 
> lldb (via the llvm's LLVMARMCodeGen) is providing the following
mnemonics:
> 
> ldr    r6, #380,
> 
> However the value for ldr is "an 8-bit value that is multiplied by 4
and added to the value of the PC to form the memory address" (via ARMARM),
so that the correct mnemonics is:
> 
> ldr     r6, [pc, #380]
> 
> (provided by Apple's otool).
> 
> I've traced the issue down to ARMInstrThumb.td:
> 
> // A8.6.57 & A8.6.60
> defm tLDR  : thumb_ld_rr_ri_enc<0b100, 0b0110, t_addrmode_rrs4,
>                                t_addrmode_is4, AddrModeT1_4,
>                                IIC_iLoad_r, IIC_iLoad_i, "ldr",
>                                UnOpFrag<(load node:$Src)>>;
> 
> In the generated TableGen output the issue lies around line 4992:
> 
> 4992	    case ARM::tUXTH: printOperand(MI, 1, O); break;
> 
> As the operand is not enough in this case.
> 
> I'm pretty stuck at the TableGen deciphering to fix the issue.
It'll be nice if someone with more llvm skills would check the file and make
the required fix.
> 
> -- 
> Vladimir Pouzanov
> http://www.farcaller.net/
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev