From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22787 invoked by alias); 23 Jun 2011 14:00:17 -0000 Received: (qmail 22772 invoked by uid 22791); 23 Jun 2011 14:00:16 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,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 14:00:01 +0000 Received: (qmail 3811 invoked from network); 23 Jun 2011 14:00:00 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jun 2011 14:00:00 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] XFAIL gdb.cp/mb-inline.exp conditionaly Date: Thu, 23 Jun 2011 14:00:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: Yao Qi References: <4DF8BEEF.5010308@codesourcery.com> <201106231128.14335.pedro@codesourcery.com> <4E034237.2040404@codesourcery.com> In-Reply-To: <4E034237.2040404@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106231459.58856.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/msg00352.txt.bz2 On Thursday 23 June 2011 14:40:07, Yao Qi wrote: > On 06/23/2011 06:28 PM, Pedro Alves wrote: > > 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. > > > > Yes, this heuristics can be improved. I have had a local hack similar > to what you suggest below, and this hack works for me. > > > 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. > > > > The key point of this approach is about identifying common base. > > My hack is similar to yours. In my hack, the offset of objfile > relocation O1 is cached. When new inferior is created again and new > object of objfile relocation offset O2 is got, we can compute the offset > A between offset of previous inferior's relocation offset (O1) and > current inferior's (O2), and then we can "relocate" breakpoint locations > with offset A. Again, it is still a hack, and some more work may be > needed here. Yes, that'd be a good approach. But you don't have a single offset though. You have potentialy one relocation offset per segment, or one per section. And its not clear locations set at addresses (b *0xf00) rather than though symbols should be relocated. At I outline "cooked" vs "raw" addresses, that I think would be an even better long term goal, which is sort of a superset of all this in that it treats addresses as base+offset. Hmmm, going back to the current mechanism, I wonder if we could use offset into section as common base (and also compare if the sections are the same). > > Anyway, I'll think of this problem. > > -- Pedro Alves