From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25347 invoked by alias); 18 Dec 2006 19:41:03 -0000 Received: (qmail 25311 invoked by uid 22791); 18 Dec 2006 19:41:02 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,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, 18 Dec 2006 19:40:56 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 3.36 #1 (Debian)) id 1GwOLu-0004P3-00; Mon, 18 Dec 2006 20:40:46 +0100 Subject: Re: fstep added From: Mark Wielaard To: Andrew Cagney Cc: frysk@sourceware.org In-Reply-To: <4586BC16.6090208@redhat.com> References: <1166450488.3022.19.camel@dijkstra.wildebeest.org> <4586BC16.6090208@redhat.com> Content-Type: text/plain Date: Mon, 18 Dec 2006 19:41:00 -0000 Message-Id: <1166470843.3022.36.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) 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: 2006-q4/txt/msg00286.txt.bz2 On Mon, 2006-12-18 at 11:04 -0500, Andrew Cagney wrote: > > You can also attach it to a running process with --pid. > > > > Most of the other utilities are now sharing a common option framework. > Can you bug report the need to convert this code. Filed as: http://sourceware.org/bugzilla/show_bug.cgi?id=3752 > > The following things can/should be improved: > > > > - It is currently build right on top of the Instruction TaskObserver. It > > might be better to build it on top of the new rt framework. The rt > > framework can probably also handle stepping over locking sequences like > > on ppc (lwarx/stwcx). > > > Yes, that's something unique to the PPC. There's an existing bug for > this under the PPC blocker list. I couldn't find the bug report. But I suppose this should be handled by the rt RunState support and not directly in the proc TaskState. > Yes, more efficient memory access will eventually be needed. For > insttance, by mmapping the inferior address space (I know there are > kernel patches out there to do that), or performing larger transfers and > caching under the hood. Both involve careful thought, especially when > it comes to invalidating caches, so for the moment, as you've done, the > focus remains on correctness. Oh, nice idea. mmapping /proc//mem would certainly speed things up. I suppose you cannot write to it, but in most cases we only need to read large amounts, not write them. > > - It could give the name of the memory map the PC is currently in. > > > > - It could even give the source/line-number if available. > > > > These are all good ideas. I added them all as a comment to the (now suspended) fstep bug http://sourceware.org/bugzilla/show_bug.cgi?id=3364 Cheers, Mark