Closed 2over12 closed 2 years ago
Most P-Code ops are being handled in the lifter now. It's really just MULTIEQUAL
and INDIRECT
that need work, but I think I'll need to reproduce those in a real example to understand what needs to happen there.
The code is mostly untested so I think I'll need to spend some time calling remill-lift
with various instructions to check that it's producing something reasonable for each P-Code op.
I think I've fixed one issue in a9fc22a. Now we're generating this for the BLX instruction that you were using:
I0418 19:23:49.282938 294978944 Arch.cpp:80] Pcode: INT_OR(register,0x58,4):lr = (const,0x4,4)(const,0x1,4)
I0418 19:23:49.282960 294978944 Arch.cpp:80] Pcode: COPY(register,0xb0,1):ISAModeSwitch = (const,0x0,1)
I0418 19:23:49.282975 294978944 Arch.cpp:80] Pcode: COPY(register,0x69,1):TB = (register,0xb0,1):ISAModeSwitch
I0418 19:23:49.282985 294978944 Arch.cpp:80] Pcode: CALL(ram,0xfff0f2d4,4)
store i32 5, i32* %LR, align 4
%2 = alloca i8, align 1
store i8 0, i8* %2, align 1
%3 = load i8, i8* %2, align 1
%4 = alloca i8, align 1
store i8 %3, i8* %4, align 1
store i32 -986412, i32* %PC, align 4
%5 = load i32, i32* %PC, align 4
store i32 %5, i32* %NEXT_PC, align 4
I think this is closer to what we want because now we're correctly generating the store to set ISAModeSwitch
to 0. The part where we do load
on %2
seems wrong though since we're using ISAModeSwitch
as a memory address for some reason. Still figuring out what to do about that.
@tetsuo-cpp One thing I'd like is for ISA mode switches to be covered in remill::Instruction::branch_taken_arch_name
. This probably means analyzing the p-code to detect the write to ISAModeSwitch
and then recovering that into the remill::Instruction
. My understanding is that the branch-not-taken / fall-through paths never change the architecture.
Implements support for thumb via sleigh