Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@vmware.com>
To: Jason Molenda <jmolenda@apple.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: [remote protocol] step range?
Date: Sat, 06 Sep 2008 01:09:00 -0000	[thread overview]
Message-ID: <48C1D803.9020602@vmware.com> (raw)
In-Reply-To: <693D921E-42E7-474A-9DCB-82FAA2DE3679@apple.com>

Jason Molenda wrote:
> On Sep 4, 2008, at 7:38 PM, Michael Snyder wrote:
> 
>> I don't think that's necessarily true -- the remote agent
>> could just do what gdb does, single-step repeatedly and
>> check the stop pc against the range.
> 
> Yeah, that'll work as long as you have some form of single-instruction-
> step support in your target environment.  If not, then you'll need a
> disassembler to (a) determine the length of the current instruction so
> you can overwrite the next instruction with a trap opcode, and (b)
> determine if the current instruction branches/calls/jumps anywhere.
> It quickly becomes Complicated.  I'm assuming you have some form of
> single-instruction-step in the target you're interested in, otherwise
> I council against pursuing this. :)
> 
> For what it's worth we use the remote protocol for debugging
> applications on the iPhone / iPod Touch devices.  When we first got it
> up and running, we saw command-line level "step" commands taking
> multiple (4-5!) seconds to complete.  We optimized it to no end and
> got this down to something like .2 seconds without doing anything too
> weird to the protocol.  We didn't have any single-instruction-step
> feature so we didn't even consider trying to push range-stepping down
> to the device.
> 
> But I don't see any problems with adding this stepping capability for
> environments that could make use of it.

The first architecture I'll be interested in will be i386-linux.
So single-stepping on the target will be no problem.

If the target can't meet the request, it will just send back
an empty reply, same as always, and gdb will fall back to some
more generic method.


  reply	other threads:[~2008-09-06  1:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04 22:15 Michael Snyder
2008-09-05  0:12 ` Jason Molenda
2008-09-05  2:39   ` Michael Snyder
2008-09-06  0:17     ` Jason Molenda
2008-09-06  1:09       ` Michael Snyder [this message]
2008-09-06  4:16       ` Daniel Jacobowitz
2008-09-07  0:35         ` Michael Snyder
2008-09-08  4:56           ` Daniel Jacobowitz
2008-09-05  2:32 ` 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=48C1D803.9020602@vmware.com \
    --to=msnyder@vmware.com \
    --cc=gdb@sourceware.org \
    --cc=jmolenda@apple.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