From: Miles Bader <miles@lsi.nec.co.jp>
To: gdb@sources.redhat.com
Subject: emulating single-step in gdbserver?
Date: Thu, 20 Feb 2003 04:39:00 -0000 [thread overview]
Message-ID: <buou1ezzhtu.fsf@mcspd15.ucom.lsi.nec.co.jp> (raw)
Hi,
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):
static void
linux_resume_one_process (struct inferior_list_entry *entry,
int step, int signal)
{
...
#ifdef PTRACE_SINGLESTEP
ptrace(step ? PTRACE_SINGLESTEP : PTRACE_CONT, process->lwpid, 0, signal);
#else
if (step)
/* 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);
#endif
...
}
void
delete_single_step_breakpoint (CORE_ADDR stopped_at)
{
struct breakpoint *bp = find_breakpoint_at (stopped_at);
if (bp)
delete_breakpoint (bp);
else
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
user-space.
A related question, BTW, is what's the precise meaning of
`the_low_target.breakpoint_reinsert_addr'? It's not documented very
well...
Thanks,
-Miles
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
or something?
--
I'd rather be consing.
next reply other threads:[~2003-02-20 4:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-20 4:39 Miles Bader [this message]
2003-02-20 13:07 ` Andrew Cagney
2003-02-20 15:08 ` Daniel Jacobowitz
2003-02-20 15:53 ` Miles Bader
[not found] ` <miles@lsi.nec.co.jp>
2003-02-20 15:31 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=buou1ezzhtu.fsf@mcspd15.ucom.lsi.nec.co.jp \
--to=miles@lsi.nec.co.jp \
--cc=gdb@sources.redhat.com \
--cc=miles@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox