From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3759 invoked by alias); 18 Feb 2010 14:10:57 -0000 Received: (qmail 3748 invoked by uid 22791); 18 Feb 2010 14:10:55 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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, 18 Feb 2010 14:10:47 +0000 Received: (qmail 26022 invoked from network); 18 Feb 2010 14:10:45 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Feb 2010 14:10:45 -0000 Date: Thu, 18 Feb 2010 14:10:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Cc: Ulrich Weigand Subject: MIPS dwarf2 location lists Message-ID: <20100218141036.GA18535@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org, Ulrich Weigand MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2010-02/txt/msg00453.txt.bz2 Hi Ulrich, Your patch here: Subject: [rfc] Fix address vs. offset handling in DWARF-2 location lists http://sourceware.org/ml/gdb-patches/2009-07/msg00378.html stopped us from using dwarf2_read_address for the offsets in location lists. The comment there talks specifically about MIPS: /* For most architectures, calling extract_unsigned_integer() alone is sufficient for extracting an address. However, some architectures (e.g. MIPS) use signed addresses and using extract_unsigned_integer() will not produce a correct result. Make sure we invoke gdbarch_integer_to_address() for those architectures which require it. This comment does apply to the calls you removed. GCC typically generates base_address == 0 and puts the whole address in the offsets. Therefore they must be sign extended, and it's gdbarch_integer_to_address which does that. So now we're getting zero-extended addresses, and they don't match anything. This ties in to my message last night, which was about a different instance of a similar bug: Subject: CORE_ADDR representation http://sourceware.org/ml/gdb/2010-02/msg00118.html Unlike the place referenced there, however, this is just comparing the results. So we have a lot of flexibility; the "abstractly right" fix would work, but so would a simple mask and check. Do you have any better idea than the attached? The tree I'm testing in is not unmodified HEAD; I'm not set up for that at the moment. I believe it has a number of other patches of similar nature to this one. -- Daniel Jacobowitz CodeSourcery 2010-02-18 Daniel Jacobowitz gdb/ * dwarf2loc.c (find_location_expression): Mask addresses before comparing. --- gdb-merged-localpatches/gdb/dwarf2loc.c 2010-02-11 12:12:07.000000000 -0800 +++ gdb-merged-postmips/gdb/dwarf2loc.c 2010-02-18 06:05:55.000000000 -0800 @@ -105,7 +105,8 @@ find_location_expression (struct dwarf2_ length = extract_unsigned_integer (loc_ptr, 2, byte_order); loc_ptr += 2; - if (pc >= low && pc < high) + if ((pc & base_mask) >= (low & base_mask) + && (pc & base_mask) < (high & base_mask)) { *locexpr_length = length; return loc_ptr;