From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1853 invoked by alias); 19 Dec 2006 10:30:38 -0000 Received: (qmail 1788 invoked by uid 48); 19 Dec 2006 10:30:22 -0000 Date: Tue, 19 Dec 2006 10:30:00 -0000 From: "mark at klomp dot org" To: frysk-bugzilla@sourceware.org Message-ID: <20061219103022.3761.mark@klomp.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/3761] New: fstep is really, really slow X-Bugzilla-Reason: AssignedTo Mailing-List: contact frysk-bugzilla-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: frysk-bugzilla-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00752.txt.bz2 List-Id: fstep 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? Memory access is not only slow for fstep. Other programs (like fcore) also could use faster access to the inferior memory. One idea (at least for read access) is mmapping the inferior address space (/proc//mem), and/or performing larger transfers and caching under the hood. -- Summary: fstep is really, really slow Product: frysk Version: unspecified Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: frysk-bugzilla at sourceware dot org ReportedBy: mark at klomp dot org OtherBugsDependingO 3364 nThis: http://sourceware.org/bugzilla/show_bug.cgi?id=3761 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.