From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <frysk-return-2101-listarch-frysk=sources.redhat.com@sourceware.org>
Received: (qmail 10763 invoked by alias); 17 Jul 2007 17:06:46 -0000
Received: (qmail 10753 invoked by uid 22791); 17 Jul 2007 17:06:46 -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; Tue, 17 Jul 2007 17:06:41 +0000
Received: from dijkstra.wildebeest.org ([192.168.1.29]) 	by gnu.wildebeest.org with esmtp (Exim 4.43) 	id 1IAqXv-0005AQ-VS; Tue, 17 Jul 2007 19:09:12 +0200
Subject: Re: Leaving visible breakpoints in memory/core (Was: Breakpoint 	stepping)
From: Mark Wielaard <mark@klomp.org>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: Roland McGrath <roland@redhat.com>, frysk@sourceware.org
In-Reply-To: <469CE381.8000705@redhat.com>
References: <20070712202339.A4D064D0489@magilla.localdomain> 	 <1184601441.3628.58.camel@dijkstra.wildebeest.org> 	 <469CE381.8000705@redhat.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mfA4tzzpIkFuDo71Xu2J"
Date: Tue, 17 Jul 2007 17:06:00 -0000
Message-Id: <1184691997.3663.49.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: <frysk.sourceware.org>
List-Subscribe: <mailto:frysk-subscribe@sourceware.org>
List-Post: <mailto:frysk@sourceware.org>
List-Help: <mailto:frysk-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: frysk-owner@sourceware.org
X-SW-Source: 2007-q3/txt/msg00136.txt.bz2


--=-mfA4tzzpIkFuDo71Xu2J
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-length: 1721

Hi Phil,

On Tue, 2007-07-17 at 10:42 -0500, Phil Muldoon wrote:
> How is this going to be implemented in the task? Are you planning on=20
> extending the abstract class Task with a getRawMemory()?

Yes. With an default implementation:

  /**=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20
   * Returns the memory as seen by frysk-core. That includes things like
   * inserted breakpoint instructions bytes which are filtered out by
   * <code>getMemory()</code> (which is what you normally want unless=20=20=
=20=20=20=20=20=20=20=20=20
   * you are interested in frysk-core specifics).
   * <p>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20
   * Default implementation calls <code>getMemory()</code>, need to be
   * overriden by subclasses for which the raw memory view and the
   * logical memory view are different.
   */
  public ByteBuffer getRawMemory()
  {
    return getMemory();
  }

> If so, what does that mean for an implementing core file task? In the=20
> corefile task (dead/LinuxTask.java) are getMemory() and getRawMemory()=20
> returning the same ByteBuffer (CorefileByteBuffer) instance?

Yes, you get the support for free.

> Is this too live process specific and should be implemented some other wa=
y?

No, I think the generic implementation is the way to go so the user
doesn't have to worry about what specific implementation instance of
Task they are using. But please do comment when I post the patch and you
feel it should be done differently.

Cheers,

Mark

--=-mfA4tzzpIkFuDo71Xu2J
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)

iD8DBQBGnPcVxVhZCJWr9QwRArA9AJ9yr6JKkNwKinlH9ox17WUCr8cXEwCgpVhL
7VvAs/+/ioZ3KzJNIDPKtG8=
=9vrL
-----END PGP SIGNATURE-----

--=-mfA4tzzpIkFuDo71Xu2J--