From: Daniel Jacobowitz <drow@mvista.com>
To: Miles Bader <miles@gnu.org>
Cc: gdb@sources.redhat.com
Subject: Re: emulating single-step in gdbserver?
Date: Thu, 20 Feb 2003 15:08:00 -0000 [thread overview]
Message-ID: <20030220150813.GA28933@nevyn.them.org> (raw)
In-Reply-To: <buou1ezzhtu.fsf@mcspd15.ucom.lsi.nec.co.jp>
On Thu, Feb 20, 2003 at 01:39:25PM +0900, Miles Bader wrote:
> 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.
GDB (i.e. the client, not gdbserver). Certainly gdbserver could do it,
but you have to do some rather more complicated work in the server that
GDB is already set up to do and the server isn't - with threads, for
instance. Most other platforms do this; see ARM and MIPS at least.
However, now that I've got limited breakpoint support in gdbserver, it
might be practical to do it in the server.
> 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?
Roughly. Another detail you'd get wrong would be if we get a signal
before hitting the single-step breakpoint - it should be removed, not
left for later. There are probably others.
> A related question, BTW, is what's the precise meaning of
> `the_low_target.breakpoint_reinsert_addr'? It's not documented very
> well...
It's essentially a very limitted next_pc function. The only
breakpoints gdbserver places right now are in empty marker functions in
the thread library. After hitting one, it either single-steps or
places a breakpoint at the function's return address, and then
reinserts it. The advantage is that finding the return address is
quick and very simple.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-02-20 15:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-20 4:39 Miles Bader
2003-02-20 13:07 ` Andrew Cagney
2003-02-20 15:08 ` Daniel Jacobowitz [this message]
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=20030220150813.GA28933@nevyn.them.org \
--to=drow@mvista.com \
--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