search

capstone-engine / capstone

Capstone disassembly/disassembler framework for ARM, ARM64 (ARMv8), Alpha, BPF, Ethereum VM, HPPA, LoongArch, M68K, M680X, Mips, MOS65XX, PPC, RISC-V(rv32G/rv64G), SH, Sparc, SystemZ, TMS320C64X, TriCore, Webassembly, XCore and X86.
http://www.capstone-engine.org
7.18k stars 1.52k forks source link

TriCore instruction loop16 #2386

Open arkup opened 3 weeks ago

arkup commented 3 weeks ago

Hi, while decoding the TriCore instruction loop16, the second operand is displayed in the format of a relative jump (not absolute), which is inconsistent with other instructions and, in my opinion (IMHO), makes it harder to read.

0x80000492: 04 FF | ld.bu d15, [a15+]
0x80000494: 24 4F | st.b [a4+], d15
0x80000496: FC 2E | loop a2, #-4               ;<===

Expected, preferred output:

0x80000492: 04 FF |  ld.bu d15, [a15+] 
0x80000494: 24 4F |  st.b [a4+], d15
0x80000496: FC 2E |  loop a2, 0x80000492       ;<===
Questions Answers
OS/arch/bits Windows x64 etc.
Architecture CS_ARCH_TRICORE, CS_MODE_TRICORE_162
Source of Capstone git clone,
Version/git commit v5.0.1, commit/3f87ce0f6a665abb2675adada507362985bb46a4

Instruction bytes giving faulty results

unsigned char loop_chars[] =
{
  0xFC, 0x2E
};

Expected results

loop16          a2, 0x...(absolut address)
XVilka commented 3 weeks ago

@imbillow could you please take a look when you have time?

imbillow commented 2 weeks ago

Hi, while decoding the TriCore instruction loop16, the second operand is displayed in the format of a relative jump (not absolute), which is inconsistent with other instructions and, in my opinion (IMHO), makes it harder to read.

0x80000492: 04 FF | ld.bu d15, [a15+]
0x80000494: 24 4F | st.b [a4+], d15
0x80000496: FC 2E | loop a2, #-4               ;<===

Expected, preferred output:

0x80000492: 04 FF |  ld.bu d15, [a15+] 
0x80000494: 24 4F |  st.b [a4+], d15
0x80000496: FC 2E |  loop a2, 0x80000492       ;<===

Questions Answers OS/arch/bits Windows x64 etc. Architecture CS_ARCH_TRICORE, CS_MODE_TRICORE_162 Source of Capstone git clone, Version/git commit v5.0.1, commit/3f87ce0f6a665abb2675adada507362985bb46a4

Instruction bytes giving faulty results

unsigned char loop_chars[] =
{
  0xFC, 0x2E
};

Expected results

loop16          a2, 0x...(absolut address)

The instruction you mention is LOOP (SBR), and its second operand is interpreted as a relative offset rather than an absolute address.

For more information, see TriCoreTM TC1.6.2 core architecture manual - Instruction set on page 3-179.

image

imbillow commented 2 weeks ago

There is indeed another instruction with the same name LOOP in a different format but it has [0..7]=0xfd

imbillow commented 2 weeks ago

I'm sorry I do not get it. But it is fixed in the next branch. @arkup

arkup commented 2 weeks ago

I'm sorry I do not get it. But it is fixed in the next branch. @arkup

OK, thanks. My point was that it's harder to read 'loop $reg, #-disp4' when I have to subtract disp4 from the loop $pc address in my head, instead of having an absolute address. In IDA/Ghidra, it's already formatted as an absolute address 'loop $reg, 0x???'