From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch
Date: Tue, 05 Dec 2000 15:24:00 -0000 [thread overview]
Message-ID: <5mk89ezc2o.fsf@jtc.redback.com> (raw)
In-Reply-To: <3A2C4141.B3C2F486@cygnus.com>
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present there are two macros that control software stepping:
Andrew>
Andrew> SOFTWARE_SINGLE_STEP_P()
Andrew>
Andrew> and SOFTWARE_SINGLE_STEP(sig, insert_or_remove)
Andrew>
Andrew> I'd like to suggest the following:
Andrew>
Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and
Andrew> add it to the *target* vector.
You're correct that hardware single step support is target dependent.
For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the
embedded sparc varients like the sparclite and sparclet), but single
step performance using the remote protocol would be greatly improved
if the stub managed the step internally. While not strictly a hard-
ware single step, it acts more or less the same. Perhaps the names
SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed
to something more appropriate? I can't think of anything off hand.
One concern I have is that it may not be known whether a target
supports "hardware" single step until it is attempts one. Using the
above examples of the sparclite and sparclet, older stubs won't have
support for the step command packet. I can't think of a good way to
determine ahead of time whether the packet is supported. GDB won't
know whether it's OK to use it until it's too late.
Perhaps this indicates we should be taking another approach. This is
not completely thought out, feel free to shoot holes in it. The step
function would be split out of target_resume() into a new vector
function target_step(). GDB would unconditionally call target_step(),
if it fails with an error code indicating that hardware single step is
not available, it would call SOFTWARE_SINGLE_STEP() and then
target_resume().
Looking at infrun.c:resume(), it looks like this wouldn't be a trivial
exercise.
--jtc
--
J.T. Conklin
RedBack Networks
next prev parent reply other threads:[~2000-12-05 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-04 17:23 Andrew Cagney
2000-12-05 6:40 ` Richard Earnshaw
2000-12-05 15:24 ` J.T. Conklin [this message]
2001-03-21 15:59 ` Todd Whitesel
2001-03-21 15:59 ` J.T. Conklin
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=5mk89ezc2o.fsf@jtc.redback.com \
--to=jtc@redback.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).