This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: STEP_SKIPS_DELAY question, sort of
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 07 Jun 2004 14:41:52 +0200
- Subject: Re: STEP_SKIPS_DELAY question, sort of
- Organization: Axis Communications
- References: <40AE38D0.7010204@axis.com> <40AE659A.90207@gnu.org> <40B1BD1B.4090300@axis.com> <40B23BB2.6070001@gnu.org> <40B33399.3090803@axis.com> <40B3B742.50007@gnu.org> <40B465E7.7050702@axis.com> <40C45B95.9050309@axis.com>
Orjan Friberg wrote:
I tried implementing a fix in handle_inferior_event (the MIPS fix is in
proceed). It seemed easier to step one more time when we find out that
we need to, rather than to determine beforehand that we're going to have
to step twice (and I couldn't determine how to pass that information).
The concept patch below illustrates what I'm trying to do; by setting
another_trap in the execution control state, by the time we get to
keep_going we won't insert the breakpoint and we'll instead continue
single-stepping. Comments? Is this the right approach at all?
Gah. Please ignore the previous patch (and sorry); what I posted only
works when doing a continue when stopped at the branch instruction.
Doing a step (which leaves us in the delay slot) followed by another
step (or continue for that matter) prematurely inserts the breakpoint.
--
Orjan Friberg
Axis Communications