This is the mail archive of the
mailing list for the GDB project.
emulating single-step in gdbserver?
- From: Miles Bader <miles at lsi dot nec dot co dot jp>
- To: gdb at sources dot redhat dot com
- Date: 20 Feb 2003 13:39:25 +0900
- Subject: emulating single-step in gdbserver?
- Reply-to: Miles Bader <miles at gnu dot org>
I'm porting gdbserver to uClinux on the (NEC) v850e processor, and
ptrace on this machine doesn't support PTRACE_SINGLESTEP (because the
hardware doesn't support single-stepping).
I thought gdb might already support an emulated singlestep by always
setting a temporary breakpoint at the next insn, but from a quick
perusal of the source, it seems not.
So I'm wondering where the best place to stick this functionality is.
My thought is to modify `linux_resume_one_process', in
gdbserver/linux-low.c, something like this (error-checking omitted):
linux_resume_one_process (struct inferior_list_entry *entry,
int step, int signal)
ptrace(step ? PTRACE_SINGLESTEP : PTRACE_CONT, process->lwpid, 0, signal);
/* This platform can't single-step, so simulate it. */
CORE_ADDR stop_pc = (*the_low_target.get_pc) ();
if (! (*the_low_target.breakpoint_at) (stop_pc))
CORE_ADDR next_pc = (*the_low_target.next_pc) ();
set_breakpoint_at (next_pc, delete_single_step_breakpoint);
ptrace (PTRACE_CONT, process->lwpid, 0, signal);
delete_single_step_breakpoint (CORE_ADDR stopped_at)
struct breakpoint *bp = find_breakpoint_at (stopped_at);
error ("Could not find single-step breakpoint in list.");
The `next_pc' member added to the_low_target would be a function that
calculates the next pc after executing the current insn.
Any comments on this approach; does it seem correct?
An alternative might be to add this to the kernel's ptrace
implementation; however, I'd rather not do this, as the `calculate the
next insn' function is a little hairy, and I'd rather it be in
A related question, BTW, is what's the precise meaning of
`the_low_target.breakpoint_reinsert_addr'? It's not documented very
p.s. Does anyone know if the gdb GNATS database is really the best place
to send bug-fix patches? I sent something there a few months ago,
and it's languished ever since, with no feedback, no change of
state, no nothing. The patch only affects the NEC v850, and is
certainly an improvement over the existing code (which is very
clearly wrong). Would it be better to send email to gdb-patches
I'd rather be consing.