This is the mail archive of the gdb-patches@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] |
Date: Wed, 15 Oct 2008 13:50:30 +0800 From: teawater <teawater@gmail.com> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
+When this target is in use, if the next instruction to be executed is in the +execution log, @value{GDBN} will debug in replay mode so that all the +execution events are taken from the execution log. Otherwise, @value{GDBN} +will debug in record mode and record the execution log while executing +normally.What exactly is the "execution log"? You talk about "next instruction", which seems to hint that the log records the machine instructions executed by the inferior -- is that true? If so, what are the "execution events" you mention here -- are they just a synonym for the "instructions", or are they something else?
"execution log" mean is before a instruction execute, record the values of register and memory that will be change in this instruction to a list.
So you record the values of registers and memory AND the instruction? The frequent use of ``instruction'' and ``insn'' is a clear hint to this; if as a matter of fact the instructions are not recorded, we should modify the text to eliminate those hints.
Eli, I think the relation is that we will save one log entry for each instruction executed. Not necessarily that we save the instruction itself, but since we do save the PC (it being part of the state that is changed by executing the instruction), we always have access to the instruction itself if we want it (either in memory or in object file).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |