From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22079 invoked by alias); 5 Sep 2008 00:12:25 -0000 Received: (qmail 22068 invoked by uid 22791); 5 Sep 2008 00:12:24 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Sep 2008 00:11:40 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 87CE83B731BF; Thu, 4 Sep 2008 17:11:39 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 6B239464002; Thu, 4 Sep 2008 17:11:39 -0700 (PDT) X-AuditID: 11807135-a717abb000000d0e-c3-48c0793be501 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 5A3AD420002; Thu, 4 Sep 2008 17:11:39 -0700 (PDT) In-Reply-To: <48C05DAF.3070705@vmware.com> References: <48C05DAF.3070705@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: <61DDBF42-6D9B-4E8C-9B0C-CB9BB68F5F11@apple.com> Date: Fri, 05 Sep 2008 00:12: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/msg00034.txt.bz2 On Sep 4, 2008, at 3:14 PM, Michael Snyder wrote: > What about a remote protocol command that says > "single step until you leave the range - ". I wouldn't imagine any problem with such a packet - but it won't be useful on architectures that have variable length instructions (even ARM with its mix of ARM and Thumb opcodes) that don't have a hardware- supported single-instruction-step capability. Your remote driver would need to contain a disassembler in those cases to do anything useful. There is a lot of overhead and unnecessary communication over a typical remote protocol connection that you can eliminate with some effort. But if the problem you're trying to solve is on a platform where single-instruction stepping is easy for the remote driver to do, this could be a reasonable alternate approach. I suppose the most complicated thing you'd have to worry about is a remote target that has multiple threads, with those threads executing when you're trying to step through that range, and one of the other threads hitting a breakpoint or getting a signal. Just my two cents, J