From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11766 invoked by alias); 18 Dec 2006 16:05:00 -0000 Received: (qmail 11597 invoked by uid 22791); 18 Dec 2006 16:05:00 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_40,SPF_HELO_PASS,SPF_PASS 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; Mon, 18 Dec 2006 16:04:53 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBIG4nDL001462; Mon, 18 Dec 2006 11:04:49 -0500 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 kBIG4nZ5013059; Mon, 18 Dec 2006 11:04:49 -0500 Received: from [10.11.14.228] (vpn-14-228.rdu.redhat.com [10.11.14.228]) by pobox.corp.redhat.com (8.13.1/8.12.8) with ESMTP id kBIG4kox016229; Mon, 18 Dec 2006 11:04:47 -0500 Message-ID: <4586BC16.6090208@redhat.com> Date: Mon, 18 Dec 2006 16:05:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Mark Wielaard CC: frysk@sourceware.org Subject: Re: fstep added References: <1166450488.3022.19.camel@dijkstra.wildebeest.org> In-Reply-To: <1166450488.3022.19.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: 2006-q4/txt/msg00281.txt.bz2 Mark Wielaard wrote: > Hi, > > I finally added my little fstep program. It is certainly not complete, > and I am not sure it is a much use as is now since it makes programs > really, really slow. But it is a nice start for the future. You can use > it as follows: > > Thanks! > 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. > 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. > - It only steps the main task. Plumbing is in place to track other > Tasks, but nothing is connected to that yet. > > - Maybe merge it completely with ftrace? > Combining single stepping and system call tracing on a Linux Kernel doesn't work :-( Probably not a good idea, at least for now :-) > - It is partially so slow because it accesses the Task memory for every > disassambly. Maybe that can be cached? Although instruction stepping is > just slow in general. An alternative could be combining stepping with > breakpoints set on "interesting functions". Or only stepping while in > the main program map, and not in any of the shared library maps? > 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. > - 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. > Note that I have marked the original tracker bug as suspended. > http://sourceware.org/bugzilla/show_bug.cgi?id=3364 > If any of the above is useful they should probably be raised as bugs and > depend on #3364. > > Cheers, > > Mark > >