Because of peculiarities in how system calls are returned from, single stepping executes some system calls and the instruction following them in a single step. Statetrace now patches the executable image when it detects a system call to force "correct" behavior, aka the appearance of stepping one instruction every single time.
--HG--
extra : convert_revision : ac6243a2e00ff98f827b005efd27b4dc5be4f774
The initial stack frame for x86 is now substantially more correct. The fixes made here can be back ported to SPARC and possible the other ISAs as well. The auxiliary vector types were moved to the LiveProcess base class because they are independent of ISA. Some of the types may only apply to Linux, though, so they may have to be moved.
--HG--
extra : convert_revision : 89ace35fcc8eb9586d2fee8eeccbc3686499ef24
The address of the stackpointer proceeding the vector minus 8 should be minus 16.
--HG--
extra : convert_revision : 648f01e9753e28391fc8d282bd9fe2bd47a0193f
The correct order is unintuitively rax, rcx, rdx, rbx, etc, not rax, rbx, rcx, rdx.
--HG--
extra : convert_revision : 3abe6a723a6e30becfe34f8da707ea2ff5d4df77
POPA used st instead of ld, and it didn't skip rsp. push rsp needs to store the -original- value of the stack pointer.
--HG--
extra : convert_revision : 376370c99b6ab60fb2bc4cd4f0a6dce71153ad06
Merge was returning the value to merge in, not the actual result of the merge.
--HG--
extra : convert_revision : 230b4b5064037d099ae7859edabdf5be84603849
The stack base on my development machine starts one page below where it needs to. I don't know why it does, but I've duplicated it in m5.
--HG--
extra : convert_revision : c4783ba885b90f17e843f61e07af0bc3330a74bc
The type constants should go into an architecture independent spot since they are universal to all Linux elf binaries. The right value for some of the vectors needs to be determined. Also, x86 does not store argc or argv_array_base in registers like some other architectures.
--HG--
extra : convert_revision : 8d3f6a3e028d881d3c41e8ddf4f29d25738b529c
Code was assuming that all argument registers followed in order from ArgumentReg0. There is now an ArgumentReg array which is indexed to find the right index. There is a constant, NumArgumentRegs, which can be used to protect against using an invalid ArgumentReg.
--HG--
extra : convert_revision : f448a3ca4d6adc3fc3323562870f70eec05a8a1f
These functions take care of calling the thread contexts read and write functions with the right sized data type, and handle unaligned accesses.
--HG--
extra : convert_revision : b4b59ab2b22559333035185946bae3eab316c879
The carry flag should be calculated using the -complement- of the second operand, not it's negation. The carry in which is part of computing the 2's complement may induce a carry, but if you've already caused the carry before you get the carry computing logic involved, it will miss it.
--HG--
extra : convert_revision : 318cf86929664fc52ed9e023606a9e892eba635c
