From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21324 invoked by alias); 4 Dec 2007 19:12:33 -0000 Received: (qmail 21279 invoked by uid 22791); 4 Dec 2007 19:12:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 19:12:26 +0000 Received: (qmail 23377 invoked from network); 4 Dec 2007 19:12:23 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Dec 2007 19:12:23 -0000 To: Mark Kettenis Cc: vladimir@codesourcery.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] Ignore breakpoints when reading memory. References: <200712011419.45773.vladimir@codesourcery.com> <200712041811.lB4IBToM005652@brahms.sibelius.xs4all.nl> From: Jim Blandy Date: Tue, 04 Dec 2007 19:12:00 -0000 In-Reply-To: <200712041811.lB4IBToM005652@brahms.sibelius.xs4all.nl> (Mark Kettenis's message of "Tue, 4 Dec 2007 19:11:29 +0100 (CET)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00058.txt.bz2 Mark Kettenis writes: >> From: Vladimir Prus >> Date: Sat, 1 Dec 2007 14:19:45 +0300 >> >> This commit prepares us for always-inserted-breakpoints mode. >> If breakpoints are always inserted, then reading the code memory >> will read the breakpoint instructions, not the original content. >> This patch makes us try to restore the original comments using >> the breakpoints table. OK? > > So now reading from target memory will need to traverse the complete > list of inserted breakpoints. Did you do any benchmarking to see what > the impact of this change is, especially when running on a somewhat > slow machine? Without taking a position on whether this is a significant problem: If we used some ordered data structure (we've got splay trees handy) to hold the breakpoint locations sorted by address, then that would permit better algorithms in some of the always-inserted breakpoint code as well. The comparison between the old and new breakpoint location lists could be linear instead of quadratic.