This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hmm, that is a significant wrinkle to the execution history theory. Basically it's not possible to know reliably whether the execution state of one CPU comes sooner or later than the state of another CPU - their clocks can't be guaranteed to be sync'ed to a sub-instruction level. It's a little like a distributed version control system, where each repository has its own version numbers, and any ordering derives from explicit push/pull instructions. Each inferior can have a reliable execution history, but if you want to go back to state X on CPU 1, you either just affect the one inferior, or expect that other inferiors will go back to the closest available state in their histories.[...] a checkpoint represents a machine state. If there are multiple machines, that complicates the picture -- but basically gdb is saying to the target "I want to be able to return to the state that you are in *right now*".
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |