This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB MI Reverse Commands added [3 of 3]
- From: Michael Snyder <msnyder at vmware dot com>
- To: Jakob Engblom <jakob at virtutech dot com>
- Cc: 'Vladimir Prus' <vladimir at codesourcery dot com>, "gdb-patches at sources dot redhat dot com" <gdb-patches at sources dot redhat dot com>
- Date: Thu, 03 Sep 2009 13:12:43 -0700
- Subject: Re: GDB MI Reverse Commands added [3 of 3]
- References: <00d001ca265a$ddd0c800$99725800$@com> <h7la0n$uvt$1@ger.gmane.org> <018401ca2cc6$7c2581a0$747084e0$@com>
Jakob Engblom wrote:
Also, I would appreciate if this:
# Test exec-reverse-next
# FIXME: Why does it take 2 next commands to get back to the
# previous line?
were somehow addressed. I am not familiar with details of reverse behaviour,
so I
did not even try to check that the tested commands and locations, etc, are
right.
Since this is tested on top of process record, I think I am not the best person
to answer... but in general, what tends to happen in reverse in my experience is
this:
We have lines of code (or instructions)
A
B
And we stop with a breakpoint in line B.
We are then at the end of B, or in the middle of B, in the execution.
Let's say lines of code, then -- it doesn't generally make sense to be
stopped in the middle of an instruction.
So to make sure we are on the same page -- we've stopped at a
breakpoint in the *MIDDLE* of line B?
Then, doing reverse one step/instruction/line will move you to the start of B.
And another step/instruction/line moves you to before A was executed.
Does that make sense for process record?
It does under the assumptions that I named above.
I suppose if we were talking about instructions that can be
interrupted in the middle, it might make sense there too.