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: Wed, 09 Jun 2004 11:48:41 +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> <40C46290.9000402@axis.com> <40C46919.2060802@axis.com> <40C484FE.5080702@gnu.org>
Andrew Cagney wrote:
Can this new mechanism somehow superseed STEP_SKIPS_DELAY - it seems to
be the exact oposite but there could be common ground here.
[proceed patch snipped]
They both seem to be asking the question: "given PC and a list of
breakpoints, should the inferior be h/w single-stepped?". That would
mean pushing the alternative:
breakpoint_here_p (read_pc () - 2)
breakpoint_here_p (read_pc () + 4)
calls into that architecture method.
Agreed. (STEP_SKIPS_IN_DELAY was just to have something to put in the patch.)
What about using the name STEP_SKIPS_DELAY for both, and introducing a
DELAY_SIZE which would return a positive value (meaning the diff from the
current pc to the delay slot) or a negative (meaning the diff from the delay
slot to the instruction preceding it)? Or does the word "size" imply an
absolute value?
[handle_inferior_event patch snipped]
I'm just not sure how this bit of logic should fit in. I'm guessing its
the second half of the state m/c sequence:
1. step off breakpoint at `PC'
2. step through delay
Unless I missed something on the way, the procedure when doing a continue from a
breakpoint that sits on the branch instruction is this:
1. proceed decides it needs to step once before continuing (since read_pc () ==
stop_pc && breakpoint_here_p (read_pc ()))
2. resume is called, with step = 1
3. target is single-stepped
4. handle_inferior_event is called (at which point we're stopped in the delay slot)
It is at this point we need to single-step again (before inserting breakpoints
again), so I set ecs->another_trap. Then:
5. keep_going is called, and since ecs->anther_trap is set, it doesn't call
insert_breakpoints.
6. resume is called again, with step = 1
7. target is single-stepped
8. handle_inferior_event is called again (but doesn't set ecs->another_trap this
time)
9. keep_going is called, and inserts the breakpoints again
I can't say where would be a better place to put the decision of whether to
single-step again. Any suggestions?
--
Orjan Friberg
Axis Communications