From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28025 invoked by alias); 14 Feb 2011 10:50:11 -0000 Received: (qmail 28010 invoked by uid 22791); 14 Feb 2011 10:50:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Feb 2011 10:50:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8E8E82BABBF for ; Mon, 14 Feb 2011 05:50:01 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sQXy7F2bjIUO for ; Mon, 14 Feb 2011 05:50:01 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 207202BABBD for ; Mon, 14 Feb 2011 05:50:01 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 648541457E4; Mon, 14 Feb 2011 14:49:55 +0400 (RET) Date: Mon, 14 Feb 2011 10:50:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: Faster stepping amidst breakpoints Message-ID: <20110214104955.GA1853@adacore.com> References: <4D3A114D.7010301@tensilica.com> <20110123001433.GA6352@caradoc.them.org> <20110131044951.GG2384@adacore.com> <20110131151229.GA2915@caradoc.them.org> <20110201032338.GI2384@adacore.com> <201102131516.p1DFGidE017378@glazunov.sibelius.xs4all.nl> <20110214032733.GV2384@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110214032733.GV2384@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-02/txt/msg00255.txt.bz2 > Maxim Grigoriev actually noticed a regression, and I also noticed > something on VxWorks. The problem on VxWorks is more or less my own fault - I'm doing something pretty shady: Inserting a breakpoint on VxWorks is done via a WTX request which returns an "eventpoint ID". To remove that breakpoint, we use the associated routine with the eventpoint ID of our breakpoint. As a result, I need to keep a mapping between breakpoint location and evenpoints IDs. I was more or less using the bp_location address as the key to my mapping (this is the shady part), hoping that it would never be reallocated. Unfortunately, this is not true at all, or at least not anymore: See breakpoint_re_set_one, which calls update_breakpoint_locations... The approach seems to be: unless all locations, recompute new locations, and then purge the old locations (update_global_location_list). The reason why this works with the current default is that the breakpoints get removed before they are re-set, and so the map gets emptied before the new locations are created. I'm thinking of adding a target_private_data field in struct bp_target_info. I think we can get away with memory management by allocating the private data at breakpoint insertion, and deallocating it at removal. That way, I get rid of the map entirely. -- Joel