Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: PAUL GILLIAM <pgilliam@us.ibm.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sources.redhat.com
Subject: Re: Instrcutions that must not be stepped.
Date: Sat, 17 Jun 2006 12:26:00 -0000	[thread overview]
Message-ID: <1150496761.3346.43.camel@dufur.beaverton.ibm.com> (raw)
In-Reply-To: <1150415676.3346.30.camel@dufur.beaverton.ibm.com>

On Thu, 2006-06-15 at 16:54 -0700, PAUL GILLIAM wrote:
> I propose changing the meaning of SOFTWARE_SINGLE_STEP_P () from "This
> arch has no hardware to do single step and must use software." to "There
> may be circumstances where this arch will have to do single stepping
> with out hardware support." And make SOFTWARE_SINGLE_STEP return 1 if a
> software single step was needed and 0 if it was not.  This would require
> a minor change for those arches currently using SOFTWARE_SINGLE_STEP and
> a little tweeking in "infrun.c".
> 
> The only difference between doing a software single step as it is now
> and doing an "atomic single step" is how the decision of where to place
> temporary breakpoints is made.

I have attached two diff's: "change_software_single_step.diff" makes the
change I proposed above.  I changed the name "software_single_step" to
"possibly_single_step_with_software".

"ppc-atomic-series.diff" should be applied after the previous patch.  It
adds the code for PowerPC on native linux that uses the new scheme and
checks for an atomic sequence.  If it find one, it prints a message to
that effect does the same type of thing as
"rs6000_possibly_single_step_with_software" after finding where to set
the breakpoints.

I have a clean compile with this, but have not done any testing yet.  I
will send these patches to gdb-patches after a bit of testing (unless I
get a huge out-cry here 8-)

-=# Paul #=-


  reply	other threads:[~2006-06-16 23:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-08  2:27 PAUL GILLIAM
2006-06-08  3:50 ` Daniel Jacobowitz
2006-06-16  4:36   ` PAUL GILLIAM
2006-06-17 12:26     ` PAUL GILLIAM [this message]
2006-06-18  4:57       ` Mark Kettenis
2006-06-20 20:13         ` PAUL GILLIAM
2006-06-20 22:53           ` Paul Koning
2006-06-20 23:34             ` PAUL GILLIAM
2006-06-21  1:17               ` Daniel Jacobowitz
2006-06-09 14:12 John Yates
2006-06-09 14:28 ` Daniel Jacobowitz
2006-06-10  0:33   ` PAUL GILLIAM

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=1150496761.3346.43.camel@dufur.beaverton.ibm.com \
    --to=pgilliam@us.ibm.com \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.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