From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12309 invoked by alias); 14 May 2012 14:39:51 -0000 Received: (qmail 12135 invoked by uid 22791); 14 May 2012 14:39:49 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BJ,TW_XF 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 May 2012 14:39:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8740A1C663C; Mon, 14 May 2012 10:39:35 -0400 (EDT) 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 y00UU-j0sUu4; Mon, 14 May 2012 10:39:35 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3BFE31C65B8; Mon, 14 May 2012 10:39:35 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7830F145616; Mon, 14 May 2012 07:39:27 -0700 (PDT) Date: Mon, 14 May 2012 14:39:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.] Message-ID: <20120514143927.GB10253@adacore.com> References: <1336430581-11262-1-git-send-email-brobecker@adacore.com> <874nrqvbeh.fsf@fleche.redhat.com> <20120509190529.GI15555@adacore.com> <20120511072606.GA25458@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120511072606.GA25458@host2.jankratochvil.net> 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: 2012-05/txt/msg00505.txt.bz2 > Running gdb/testsuite/gdb.fortran/library-module.exp ... > -PASS: gdb.fortran/library-module.exp: print var_i in lib > +FAIL: gdb.fortran/library-module.exp: print var_i in lib > -PASS: gdb.fortran/library-module.exp: print var_i in main > +FAIL: gdb.fortran/library-module.exp: print var_i in main Jan and I discussed this briefly on IRC, and here is what's happening. The `lib' unit, which is compiled into a shared library, defines a global named var_i. The main subprogram makes a reference to that variable. What happens in our case is something that Jan called copy-relocation. Quoting Jan: From the naive programmer's point of view there is single variable. But sure technically there are two copies of that variable, due to copy-relocation. The variable located in the .so file is dead and GDB must not use it. But GDB has some bugs in it. Just Looking at the debugging information, we indeed see 2 definitions for that global variable: . The first one is of course the global variable defined in the `lib' module: <1>: Abbrev Number: 3 (DW_TAG_variable) DW_AT_name : var_i DW_AT_MIPS_linkage_name: __lib__var_i DW_AT_type : <0xfb> DW_AT_external : 1 DW_AT_location : 9 byte block: 3 f8 8 20 0 0 0 0 0 (DW_OP_addr: 2008f8) . And then the second instance, which is defined as an external variable, but within the scope of the main subprogram (that's the `<2>' on the first line: <2>: Abbrev Number: 3 (DW_TAG_variable) DW_AT_name : var_i DW_AT_MIPS_linkage_name: __lib__var_i DW_AT_type : <0x106> DW_AT_external : 1 DW_AT_declaration : 1 There is no DW_AT_location for the second one, so I assume we go through the minimal symbol table to get its actual address. The Fortran implementation is taking advantage of the fact that the executable is always going to be the first objfile being searched by ALL_OBJFILES. My patch breaks that assumption. Jan also seems to think that we may have the same sort of issue with C++ but we do not have a reproducer. I had some time to think this over during the weekend, and only see two solutions: (1) Back my patch out, which I think would be a real shame; (2) Conditionalize my patch on the current language. If the current language is Fortran, then loop over the objfiles as before. I am a little unhappy about adding a reference to the current language, but I don't see a way to infer any meaningful language from the data we have in lookup_symbol_global (we have the objfile's global block, and a domain_enum). There is an intermediate solution, which is to always search the main objfile first, and then the current DSO, and then the rest. I think that'd be getting a little too complicated to explain to the average user... Thoughts? -- Joel