Problem with the use of registers about asmjit

[kobalicek]

I will try to solve this, but I would like to ask you for few things before:

1. Pull the recent version from master (there are some improvements to make debugging easier)
2. Name your variables (parameter after variable type)

I fixed some issues recently, but sure this is something else. Basically I don't know where the EAX/RAX comes from, it seems it was a return value of the function to me, but I'm not sure. Maybe also more code would help.

Thanks!

[LemonBoy]

; OP_MSR_CPSR ; REG_OFF mov eax, dword ptr [rbx+16] ; mov operand, [cpu_ptr+16] r.. w mov ecx, dword ptr [rbx+80] ; mov mode, [cpu_ptr+80] r.. .w and ecx, 31 ; and mode, 31 ... .x cmp ecx, 16 ; cmp mode, 16 ... .R je L4 ; je L4 ... . mov esi, dword ptr [rbx+16] ; mov mode, [cpu_ptr+16] r.. .w and esi, 31 ; and mode, 31 ... .x mov rdi, rbx ; [Move] cpu_ptr mov [rsp+12], eax ; [Save] operand call 5641104 ; r.. .R int 3 ; int 3 ... . mov ebx, dword ptr [r13+80] ; mov xPSR, [cpu_ptr+80] r.. . w mov r14d, [rsp+12] ; [Alloc] operand and r14d, -16776961 ; and operand, -16776961 ... x . and ebx, 16776960 ; and xPSR, 16776960 ... . x or ebx, r14d ; or xPSR, operand ... R x mov dword ptr [r13+80], ebx ; mov [cpu_ptr+80], xPSR r.. R jmp L5 ; jmp L5 ... L4: mov r13d, dword ptr [rbx+80] ; mov xPSR, [cpu_ptr+80] r.. . w and eax, -16777216 ; and operand, -16777216 ... x . and r13d, 16777215 ; and xPSR, 16777215 ... . x or r13d, eax ; or xPSR, operand ... R x mov dword ptr [rbx+80], r13d ; mov [cpu_ptr+80], xPSR r.. R mov r13, rbx ; [Move] cpu_ptr mov [rsp], r13 ; [Save] cpu_ptr L5: call 4525776 ; ... add ebp, 1 ; add total_cycles, 1 .x. add r12d, 4 ; add v3, 4 ..x

Different code, same error.
I've added some names here and there to aid debugging but the codebase is huge and it'll take some time to name them all. The int3 was added on purpose to help me trace the code flow.
The function that is called has a return address that is ignored (no setRet), can this interfere with the stack handling somehow ?

[kobalicek]

Thanks, this is something I can play with a bit.

I have a suspicion that it's caused by the function argument 'u8'. I would try to use uint32_t in your case and see if the problem persists. Anyway I'm going to add more test cases and hopefully will be lucky.

[kobalicek]

I think i have hit this issue or at least something similar. Will focus on test-cases and fixing today/tomorrow.

[kobalicek]

Please check out branch issue9 and let me know if it fixes the issue completely since I did only limited testing.

[LemonBoy]

I've tested it for a couple of minutes and it seems to work fine!
I'll do more testing in the evening anyway :)

[kobalicek]

Ok, I'm closing this one, if you find any other issue related to function-call please reopen.