Re: [GXemul-devel] ARM SBC instruction emulation does not set CPSR oVerflow bit
Status: Alpha
Brought to you by:
gavare
From: Nilsson J. (ETAS-SEC/ENG-IDS) <Joe...@se...> - 2019-03-21 13:39:06
|
Ok, I think I found the problem in cpu_arm_instr_dpi.cc. I have changed the code to: #if defined(A__SBC) || defined(A__RSC) c64 = a - b - (cpu->cd.arm.flags & ARM_F_C? 0 : 1); #endif Best regards, Joergen From: Nilsson Joergen (ETAS-SEC/ENG-IDS) Sent: den 21 mars 2019 10:54 To: 'gxe...@li...' <gxe...@li...> Subject: ARM SBC instruction emulation does not set CPSR oVerflow bit Hello gxemul developers, I have recently come across an anomaly in the emulation of the ARM SBC instruction. The case is as below. GXEMUL VERSION: 0.6.1 ENVIRONMENT: Debian COMMAND: gxemul -E 'testarm' mysimpleapp CODE: #include <inttypes.h> int main(void) { int ret = 0; int64_t min_signed = INT64_MIN; int64_t max_signed = INT64_MAX; if (max_signed > min_signed) { ret = 0; } else { ret = -1; } return ret; } COMPILER: gcc-arm-non-eabi RESULT: Main returned nonzero! DEBUG INFO (BEFORE): 0001023c: e0d23004 sbcs r3,r2,r4 BREAKPOINT: pc = 0x1023c (The instruction has not yet executed.) GXemul> reg cpu0: cpsr = nzcvqjeaIFt pc = 0x0001023c <main+0x68> cpu0: r0 = 0x00000000 r1 = 0x00000000 r2 = 0x80000000 r3 = 0xfffffffe cpu0: r4 = 0x7fffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 cpu0: r8 = 0x00000000 r9 = 0x00000000 sl = 0x00000000 fp = 0x0001c9cc cpu0: ip = 0x00000000 sp = 0x0001c9a0 lr = 0x00010028 cpu0: cpsr = 0x000000d3 (SVC32) DEBUG INFO (AFTER): GXemul> step 0001023c: e0d23004 sbcs r3,r2,r4 GXemul> reg cpu0: cpsr = nZCvqjeaIFt pc = 0x00010240 <main+0x6c> cpu0: r0 = 0x00000000 r1 = 0x00000000 r2 = 0x80000000 r3 = 0x00000000 cpu0: r4 = 0x7fffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 cpu0: r8 = 0x00000000 r9 = 0x00000000 sl = 0x00000000 fp = 0x0001c9cc cpu0: ip = 0x00000000 sp = 0x0001c9a0 lr = 0x00010028 cpu0: cpsr = 0x600000d3 (SVC32) The expected is that the oVerflow bit of the CPSR is set, i.e. that CPSR is 0x700000d3. Could anyone guide me as how to resolve this problem in the correct manner? I guess there is an update of the cpu_arm_instr_dpi.cc needed. Best regards, Joergen |