From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32404 invoked by alias); 27 Apr 2006 01:37:22 -0000 Received: (qmail 32395 invoked by uid 22791); 27 Apr 2006 01:37:21 -0000 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; Thu, 27 Apr 2006 01:37:20 +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 k3R1bH1c004924; Wed, 26 Apr 2006 21:37:17 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3R1bG3b031066; Wed, 26 Apr 2006 21:37:16 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k3R1bEtt023223; Wed, 26 Apr 2006 21:37:15 -0400 Message-ID: <4450204A.1020503@redhat.com> Date: Thu, 27 Apr 2006 01:37:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sourceware.org Subject: Re: [RFC] problem fetching inferior memory due to breakpoint References: <20060426190517.GA930@adacore.com> <20060426191946.GA28844@nevyn.them.org> <20060426211817.GB930@adacore.com> <20060426213923.GA6253@nevyn.them.org> <20060426221801.GC930@adacore.com> <20060426222904.GA9745@nevyn.them.org> <44500338.4090808@redhat.com> <20060427004221.GA12481@nevyn.them.org> In-Reply-To: <20060427004221.GA12481@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00356.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Apr 26, 2006 at 04:33:12PM -0700, Michael Snyder wrote: > >>You know what might be a good optimization? >> >>Take "breakpoints_inserted" out of infcmd, stick it in breakpoint.c, >>and export an access method. It makes no sense for anybody except >>breakpoint.c to be keeping track of this anyway. >> >>Then, read_memory_no_bpt can simply check this, and if it's not set, >>default to target_read_memory. > > > True - but not in the big picture. If there's enough breakpoints that > walking the linked list checking ->inserted is a problem, think how > much more of a problem removing them and inserting them every step time > must be. I must not have made myself clear. I didn't mean to suggest any change as to when or how often breakpoints are inserted. My suggestion relates to when and how often we would have to walk the list of breakpoints before reading memory. If the breakpoints_inserted flag were made globally available (thru an accessor method, of course), then there is a really inexpensive way to determine that the list-walking step may be skipped.