From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15209 invoked by alias); 23 Jun 2011 10:28:32 -0000 Received: (qmail 15198 invoked by uid 22791); 23 Jun 2011 10:28:31 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 10:28:16 +0000 Received: (qmail 7034 invoked from network); 23 Jun 2011 10:28:16 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jun 2011 10:28:16 -0000 From: Pedro Alves To: Yao Qi Subject: Re: [patch] XFAIL gdb.cp/mb-inline.exp conditionaly Date: Thu, 23 Jun 2011 10:28:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <4DF8BEEF.5010308@codesourcery.com> <201106221638.30062.pedro@codesourcery.com> <4E030591.6040709@codesourcery.com> In-Reply-To: <4E030591.6040709@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106231128.14335.pedro@codesourcery.com> 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: 2011-06/txt/msg00342.txt.bz2 On Thursday 23 June 2011 10:21:21, Yao Qi wrote: > On 06/22/2011 11:38 PM, Pedro Alves wrote: > > The breakpoint was set by line number, and we're reloading > > the session the same both times. Why does breakpoint 1.2 become > > enabled (and I'm guessing that breakpoint 1.1 becomes disabled)? > > > > No, in my case, both 1.1 and 1.2 becomes enabled. > info break^M > Num Type Disp Enb Address What^M > 1 breakpoint keep y ^M > breakpoint already hit 3 times^M > 1.1 y 0xe78c90a8 in foo(int) at > gdb/testsuite/gdb.cp/mb-inline.h:26^M > 1.2 y 0xe78c91a8 in foo(int) at > gdb/testsuite/gdb.cp/mb-inline.h:26^M > > During breakpoint updates (when inferior is re-created), GDB will > iterate list of breakpoint locations, to look for breakpoint locations > for a certain address in new inferior, and assign found breakpoint > locations to that breakpoint. The state of breakpoint location > (enabled/disabled) is kept, and this test will pass. > > If gdb is unable to find any breakpoint location for a given address, > gdb will create new breakpoint locations, and remove old breakpoint > location. Then, the state of breakpoint location of previous inferior > is lost, and new created breakpoint location is enabled in default. Okay, that happens when the locations have ambiguous names, at the end of update_breakpoint_locations. You're just re-running the same binary, and the breakpoints are even all set in the same objfile. Nothing changed from the user's perpective. It's reasonable to expect gdb manages to not lose track of the disable state. I think we can and should improve the heuristic to handle this scenario. Instead of comparing absolute addresses, normalize them before comparing. E.g., Before After 0x400010 0x800010 0x401000 0x801000 0x410000 0x810000 0x400100 0x800100 For each list, find some common base and subtract it from each entry, and _then_ compare the locations: Before After 0x000010 0x000010 0x001000 0x001000 0x010000 0x010000 0x000100 0x000100 The common base might be the lowest address in each list, or something else, like the objfile's lowest address, or some such. If we had some sort of unique symbol hash id, we could use that instead, and it'd be more reliable, me thinks. -- Pedro Alves