From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20620 invoked by alias); 22 Jan 2007 16:19:33 -0000 Received: (qmail 20613 invoked by uid 22791); 22 Jan 2007 16:19:32 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_05,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 22 Jan 2007 16:19:24 +0000 Received: from hermans.wildebeest.org ([192.168.1.28]) by gnu.wildebeest.org with esmtp (Exim 3.36 #1 (Debian)) id 1H91t2-0001KW-00; Mon, 22 Jan 2007 17:19:12 +0100 Subject: Re: fstep added From: Mark Wielaard To: Phil Muldoon Cc: Andrew Cagney , frysk@sourceware.org In-Reply-To: <45B4C173.5010909@redhat.com> References: <1166450488.3022.19.camel@dijkstra.wildebeest.org> <4586BC16.6090208@redhat.com> <45B4C173.5010909@redhat.com> Content-Type: text/plain Date: Mon, 22 Jan 2007 16:19:00 -0000 Message-Id: <1169482750.29512.1.camel@hermans.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00033.txt.bz2 On Mon, 2007-01-22 at 07:51 -0600, Phil Muldoon wrote: > Resurrecting this thread for a little bit. Is this issue related to: > > http://sourceware.org/bugzilla/show_bug.cgi?id=3727 > > I'm hazarding a guess this all comes down to ptrace accessing the > inferior's memory word by word, and that optimizations made in access to > the inferior's memory (ie by mmaping /proc/$$/memory) will benefit fcore > as well as fstep? My knowledge here is really fuzzy. Yes and http://sourceware.org/bugzilla/show_bug.cgi?id=3761 which are basically the same issue. To speedup fstep and fcore) we would like to mmap /proc//mem for the inferior and wrap it in an inua ByteBuffer. This doesn't provide write access, but we do reads mostly anyway. You can imagine a ByteBuffer returned by Task.getMemory() that delegates reads through such an mmap backed inua ByteBuffer and writes delegated through a ptrace backed inua ByteBuffer. Cheers, Mark