From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19351 invoked by alias); 10 Jul 2007 18:06:55 -0000 Received: (qmail 19342 invoked by uid 22791); 10 Jul 2007 18:06:54 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS,TW_FH X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jul 2007 18:06:52 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6AI6npQ010827; Tue, 10 Jul 2007 14:06:49 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6AI6mJJ025826; Tue, 10 Jul 2007 14:06:48 -0400 Received: from localhost.localdomain (vpn-14-79.rdu.redhat.com [10.11.14.79]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l6AI6lwV024565; Tue, 10 Jul 2007 14:06:47 -0400 Message-ID: <4693CAB6.8060809@redhat.com> Date: Tue, 10 Jul 2007 18:06:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Mark Wielaard CC: frysk@sourceware.org Subject: Re: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping) References: <1183573205.3598.157.camel@dijkstra.wildebeest.org> <468C7757.3050105@redhat.com> <1183639162.32586.24.camel@dijkstra.wildebeest.org> <1184061552.3607.25.camel@dijkstra.wildebeest.org> In-Reply-To: <1184061552.3607.25.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-q3/txt/msg00073.txt.bz2 Mark Wielaard wrote: > Hi Phil, > > 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!) > Well I think in the kernel dumping core there is nothing to be done with 2) other than just let it happen. I just wonder if the entry-point of the program being rewritten by Frysk in this scenario will cause confusion. In the case of fcore, we can always strip all this stuff beforehand, dump the core, and then put it all back. But in the case of gcore and google's coredumper that won't be the case. A process has no idea when a userland program like gcore/fcore is creating a coredump of it. However until there is a better place to store this stuff other than at the entry-point address, then I guess the question it sort of moot. Regards Phil > 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 >