From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14472 invoked by alias); 10 Jul 2007 09:59:18 -0000 Received: (qmail 14464 invoked by uid 22791); 10 Jul 2007 09:59:18 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,TW_FH 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, 10 Jul 2007 09:59:16 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1I8CXQ-0000HU-7D; Tue, 10 Jul 2007 12:01:44 +0200 Subject: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) From: Mark Wielaard To: Phil Muldoon Cc: frysk@sourceware.org In-Reply-To: <1183639162.32586.24.camel@dijkstra.wildebeest.org> References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6LJBSpsxZYp6QPJn89ut" Date: Tue, 10 Jul 2007 09:59:00 -0000 Message-Id: <1184061552.3607.25.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/msg00059.txt.bz2 --=-6LJBSpsxZYp6QPJn89ut Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1681 Hi Phil, On Thu, 2007-07-05 at 14:39 +0200, Mark Wielaard wrote: > > Though I=20 > > suspect if you are dumping core while stepping a process one is in=20 > > deeper trouble than one suspects ;) >=20 > I admit to not have thought of this scenario. That is indeed troublesome > since some breakpoints might actually still be embedded in the Proc code > memory while the kernel writes out the core file. Have to think about > that. What scenarios are there for a process to dump core? And is there > any way for us to intercept and quickly remove any changes we done to > the code segments before that? After thinking about it a bit more and some off-list chatter I think there are 2 scenarios here. 1) Having our inserted breakpoints show up in memory views as used in frysk. 2) Inserted breakpoints show up in core dumps of programs we are analyzing. It is probably not worth it to worry about 2) since as you say the user has deeper troubles then. And if they want to analyse the actual core file later on it is probably even more fair to make sure the breakpoints are still in the core file so they have a real picture of what went wrong (it could even have been frysk's fault!) But 1) is a problem since it would distort the view of the user while using frysk. So there is now bug #4761 and it is on my TODO list to create a memory view that the "non-breakpoint aware" parts of Frysk will use for memory inspection. The use case is to have the fhpd or frysk-gui insert a breakpoint, stop at it, and let the user inspect the code instructions around the breakpoint. This should not show traces of the breakpoint even though frysk might still have it inserted. Cheers, Mark --=-6LJBSpsxZYp6QPJn89ut 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) iD8DBQBGk1hqxVhZCJWr9QwRAqTvAJ4orLtRIjrKCKCX8BohS9Xirj/9IACfcItg oO0ky0EfRnsmdQhCPpsxh4M= =J8Yb -----END PGP SIGNATURE----- --=-6LJBSpsxZYp6QPJn89ut--