And running 64-bit machine code in 32-bit mode wouldn't explain your observations either. We know you're in 64-bit mode, not 32-bit compat mode, otherwise rsp wouldn't be a valid register. Unless you're accidentally setting some other bit in FLAGS that breaks execution? There are bits in EFLAGS/RFLAGS other than condition codes, including the single-step TF Trap Flag: debug exception after every instruction. Presumably popf also assembles as popfw, only popping 2 bytes into FLAGS instead of the normal 8 bytes into RFLAGS. In Visual Studio / MASM, apparently (according to OP's comment) pushf assembles as pushfw, 66 9C which pushes 2 bytes. There's little reason to mess around with 16-bit operand size, but that's probably not your problem. Make sure your debugging tools work properly and aren't being fooled by something into falsely showing a "jump" to somewhere. Mostly this answer is just providing some background not a real answer, and a suggestion not to use pushf/popf in the first place for performance reasons. Your reported behaviour doesn't really make sense. add rsp, 28h works with or without this!!! sub rsp, 28h works with or without this!!! However if I use this code it works as expected: PUBLIC Rora_I_A Op 46 - Rotate Right through Carry A reg Pushf this causes jump to end of program ?Ĭall SaveFlagsCmb NZ from the add and CF saved in dx add 0 to result to trigger Zero and Sign/Neg flags Rotate Right the byte and save the FLAGS PUBLIC Rora_I_A Op 46 - Rotate Right through Carry A reg The code represents an emulated 6809 CPU Rora (Rotate Right Register A). SaveFlagsCmb is an assembly function but could easily be a macro. So I tried removing this from both routines but it made no difference. However I noticed that this is only necessary when the assembly code calls a C function. In the routines I usually setup and clean up the stack with : Since my work around works as expected I would like to know why using the pushf instruction appears to be (I assume) corrupting the stack. This code is called from a C function which is several call levels deep and the pushf causes program execution to revert back several levels through the stack and completely exit the program. I think my real problem is I don't completely understand the stack frame mechanism so I am looking to understand why the following code causes the program execution to resume at the end of the application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |