Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "John Yates" <jyates@netezza.com>
To: "Daniel Jacobowitz" <drow@false.org>,
		"PAUL GILLIAM" <pgilliam@us.ibm.com>
Cc: <gdb@sources.redhat.com>
Subject: RE: Instrcutions that must not be stepped.
Date: Fri, 09 Jun 2006 14:12:00 -0000	[thread overview]
Message-ID: <4D87F853B8020F4888896B1507DC0F090268F0@mail2.netezza.com> (raw)

Daniel Jacobowitz writes:

> Nope.  You'd have to add one.  And, you'd have to be able to tell
> whether you were in the middle of a GDB-automated step or a user stepi;
> stepping multiple instructions when the user asked for one is probably
> just confusing.

To whom or what?  I would be quite happy if gdb did the right thing
and output a message to the effect that an atomic sequence was indeed
treated as atomic.  That is the count of instructions stepped changed
by one for any number of failed attempts and then one final successful
execution of the entire atomic sequence.

> Reading the instruction before stepping is going to slow down single
> stepping.  Is there some other way we can handle this?

The overhead could be ameliorated by having the status returned from
a completed single step include an optional assertion that if gdb were
to step again without altering the pc or the contents of memory at the
address referenced by the pc then that step would initiate an atomic
sequence.

With this mechanism the first attempt to single step after a period of
non-single stepped execution would need to check the first instruction;
after that the process would be self sustaining without any addition
gdb initiated instruction inspection.

Admitted this mechanism does not absolve the greater gestalt of gdb +
stub + single step break handle from needing to retrieve and inspect
instructions.  But it may push it to a point where the overhead becomes
acceptable.

/john


             reply	other threads:[~2006-06-09 13:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09 14:12 John Yates [this message]
2006-06-09 14:28 ` Daniel Jacobowitz
2006-06-10  0:33   ` PAUL GILLIAM
  -- strict thread matches above, loose matches on Subject: below --
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
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

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=4D87F853B8020F4888896B1507DC0F090268F0@mail2.netezza.com \
    --to=jyates@netezza.com \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=pgilliam@us.ibm.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