This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Re: Code Flow for RTL generation


Daniel Jacobowitz wrote:

The point of going backwards (a feature quite familiar to me from
the use of hardware debuggers on PC's in bygone years) is to figure
out what went wrong, and for that purpose you only need to worry
about the machine/memory state.

Not when you're debugging userspace and you have files.

I just don't see that at all, if you can back up to previous memory states, where the entire machine state is reproduced that's good enough. When you run forward from the backward point, you just reproduce the I/O behavior that the program execution actually saw.

You absolutely do want to insulate yourself from the external
environment when in this "backed up" mode, because, especially
in the presence of asynchronous events redoing the I/O won't
work. FOr example, if you are accessing a shared database,
then the database may change after the interruption point.
You don't want those changes to affect your attempts to find
out what went wrong.

The board I had on my PC recorded the last few thousand bus
cycles, including all I/O cycles, and simply unplayed or
replayed these from its buffer, so you were ensured that
you could exactly reproduce and replay the history leading
up to the interruption point. That's what you ideally need
for debugging.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]