From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25573 invoked by alias); 6 Sep 2008 00:17:10 -0000 Received: (qmail 25563 invoked by uid 22791); 6 Sep 2008 00:17:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Sep 2008 00:16:20 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id E08C33A07C14; Fri, 5 Sep 2008 17:16:18 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id CBA2B464003; Fri, 5 Sep 2008 17:16:18 -0700 (PDT) X-AuditID: 11807135-ac985bb000000d0e-d6-48c1cbd258f1 Received: from [17.201.22.22] (moleja2.apple.com [17.201.22.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay12.apple.com (Apple SCV relay) with ESMTP id B6B78420004; Fri, 5 Sep 2008 17:16:18 -0700 (PDT) In-Reply-To: <48C09B98.3010506@vmware.com> References: <48C05DAF.3070705@vmware.com> <61DDBF42-6D9B-4E8C-9B0C-CB9BB68F5F11@apple.com> <48C09B98.3010506@vmware.com> From: Jason Molenda Mime-Version: 1.0 (Apple Message framework v1023) To: Michael Snyder Content-Type: text/plain; delsp=yes; charset=us-ascii; format=flowed Message-Id: <693D921E-42E7-474A-9DCB-82FAA2DE3679@apple.com> Date: Sat, 06 Sep 2008 00:17:00 -0000 Content-Transfer-Encoding: 7bit Cc: "gdb@sourceware.org" Subject: Re: [remote protocol] step range? X-Mailer: Apple Mail (2.1023) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00038.txt.bz2 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. > Well, if the remote can deal with threads at all (eg. gdbserver), > then it could probably treat this just as gdb would. A preemptive > stop in another thread would be outside the step range, therefore > we would tell gdb that we stopped. Since we've established that you must have single-instruction-step capability in the target to do this, I think it's safe to assume that only the current continue thread will execute. But as you say, if the remote agent determines that it stopped in a different thread than it began the step, it can give up and return control to gdb. J