From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14941 invoked by alias); 10 Jul 2007 13:52:32 -0000 Received: (qmail 14929 invoked by uid 22791); 10 Jul 2007 13:52:31 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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 13:52:29 +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 l6ADqO7w005348; Tue, 10 Jul 2007 09:52:24 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6ADqNs8029172; Tue, 10 Jul 2007 09:52:23 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6ADqLQo027420; Tue, 10 Jul 2007 09:52:22 -0400 Message-ID: <46938F27.2030808@redhat.com> Date: Tue, 10 Jul 2007 13:52:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Mark Wielaard CC: Phil Muldoon , 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/msg00064.txt.bz2 Mark, Expanding on our discussion: -> user examining memory: breakpoints invisible -> process dumps core via kernel: breakpoints are visible (no choice with current kernel infrastructure) -> user requests fcore: breakpoints should not be visible I.e., breakpoints and their implementation are not visible to the user (or beyond frysk.proc) However, for our own debugging sanity, we will also need a way to examine the raw/modified memory to see what the program is really executing :-) Andrew Mark Wielaard wrote: > Hi Phil, > > On Thu, 2007-07-05 at 14:39 +0200, Mark Wielaard wrote: > >>> Though I >>> suspect if you are dumping core while stepping a process one is in >>> deeper trouble than one suspects ;) >>> >> 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 >