From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9816 invoked by alias); 6 Aug 2007 09:17:55 -0000 Received: (qmail 9465 invoked by uid 22791); 6 Aug 2007 09:17:53 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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, 06 Aug 2007 09:17:50 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1IHylK-00042m-NH; Mon, 06 Aug 2007 11:20:31 +0200 Subject: Re: [patch] LogicalMemoryBuffer From: Mark Wielaard To: Phil Muldoon Cc: frysk In-Reply-To: <46B335A4.6020503@redhat.com> References: <1184932926.3611.58.camel@dijkstra.wildebeest.org> <1186053948.15044.61.camel@dijkstra.wildebeest.org> <46B335A4.6020503@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zshcU2NENKbeSjcQCffM" Date: Mon, 06 Aug 2007 09:17:00 -0000 Message-Id: <1186391866.3766.24.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Spam-Score: -4.4 (----) X-Virus-Checked: Checked by ClamAV on sourceware.org 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-q3/txt/msg00267.txt.bz2 --=-zshcU2NENKbeSjcQCffM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 2452 Hi Phil, On Fri, 2007-08-03 at 09:03 -0500, Phil Muldoon wrote: > Mark Wielaard wrote: > > On Fri, 2007-07-20 at 14:02 +0200, Mark Wielaard wrote: > >> - LogicalMemoryBuffer is a filter on top of AddressSpaceByteBuffer but > >> really should be on top of MemorySpaceByteBuffer which is more > >> effecient. The used to be interface compatible, but a recent change to > >> MemorySpaceByteBuffer changed that and made that it less easy to wrap. > >> MemorySpaceByteBuffer is really just an optimization of > >> AddressSpaceByteBuffer (in the case of AddressSpace.TEXT/DATA) and all > >> code should go through the optimized path (StateLessFile) for accessing > >> memory if the AddressSpace allows it. So I am going to merge the two > >> (and fix up the places that currently use the slow path). Then I'll al= so > >> add the ByteBuffer.get() optimization that Chris pointed out. > >>=20=20=20=20=20 >=20 > Can you write up the difference between Logical and Raw Memory? How is=20 > Raw memory exported? If a break-point has been added to memory 0x123434=20 > is the map marked as written in RawMemory? Good questions. See also the Task getRawMemory() interface documentation. getMemory() and getRawMemory() are somewhat independent of the MemoryMaps returned by getMaps(). You can get the actual bytes of the address ranges given in the MemoryMap through either the ByteBuffer returned by getMemory(), which gives you the logical memory view (without any "artificial" changes made by frysk-core) or through the ByteBuffer returned by getRawMemory() that includes also any changes to the memory made by frysk-core. Since there is only one getMaps() variant the flags set on the returned MemoryMaps correspond to the "raw" memory view. So a MemoryMap could be marked as written to, but if you access its content through the getMemory() ByteBuffer you would still not see the frysk-core change. If it is beneficial for your use case we could add an extra flag to MemoryMap saying whether or not it (also) contains changes were made by frysk-core. Note however that the kernel doesn't track the "why" of a write to the map, so it doesn't distinguish between whether a monitoring app like frysk did it, or whether the application itself or the kernel wrote to the map. And as Roland said there is no way to "reverse" a write, once written, even if you put back the original contents later, it will always be marked as written by the kernel. Cheers, Mark --=-zshcU2NENKbeSjcQCffM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGtuc1xVhZCJWr9QwRArEIAJ91SxRXgXSmSAguGnMLIH09E//+9wCcDOiz h0XIi0tGITkYKLAvQZDHkyU= =T/DV -----END PGP SIGNATURE----- --=-zshcU2NENKbeSjcQCffM--