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.

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.