From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12706 invoked by alias); 30 Jan 2012 20:08:04 -0000 Received: (qmail 12666 invoked by uid 22791); 30 Jan 2012 20:08:02 -0000 X-SWARE-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_STOCKTIP,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from caibbdcaaaaf.dreamhost.com (HELO homiemail-a50.g.dreamhost.com) (208.113.200.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jan 2012 20:07:49 +0000 Received: from homiemail-a50.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTP id EF3136F8065 for ; Mon, 30 Jan 2012 12:07:48 -0800 (PST) Received: from redwood.eagercon.com (c-76-102-3-160.hsd1.ca.comcast.net [76.102.3.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 09DCF6F8060 for ; Mon, 30 Jan 2012 12:07:48 -0800 (PST) Message-ID: <4F26F891.5040308@eagerm.com> Date: Mon, 30 Jan 2012 20:08:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Copy-Relocate debug error Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00120.txt.bz2 Here is a small test program which uses copy-relocate on X86_64. Gdb-7.2 gives the wrong value when a global symbol is printed when stopping in a function in the shared library. gdb-7.3 (and later) give the correct result. I'm not sure that they get the correct result because a problem in gdb-7.2 was fixed rather than by accident. Here's the test program: $ cat tmp.c extern int tab[100]; int main (void) { tab[10] = 10; sub (); return 0; } $ cat libtmp.c int tab[100] = {2,4,6}; void sub (void) { tab[20] = 20; } $ gcc -fpic --shared -g -o libtmp.so libtmp.c $ gcc -g tmp.c libtmp.so -Wl,-R,`pwd` Running gdb: $ gdb a.out (gdb) b sub (gdb) run (gdb) info addr tab Symbol "tab" is static storage at address 0xxxxxx. On gdb-7.2, the address given is for the copy of 'tab' in the shared library. This is not the one which sub() is using. Sub() references 'tab' indirectly through the GOT, which the run time loader has set to point to the copy of 'tab' in the executable which it created as a result of the R_X86_64_COPY for 'tab' in tmp.c. The code to reference 'tab' in sub() is: mov 0x200285(%rip),%rax # 200890 <_DYNAMIC+0x1d0> When gdb-7.2 searches for 'tab', it finds the symbol in the shared library symbol table with the address specified by this DWARF location: DW_OP_addr tab This is incorrect. The correct DWARF should describe the code: DW_OP_addr tab@GOT DW_OP_deref If I change the DWARF data for 'tab', gdb complains that this is a "complex expression", which is not supported. gdb-head gives the correct result because the symbols for a.out are read as a side-effect of walking the frame chain and it finds the global definition for 'tab' in a.out, never looking at the symbols (or DWARF info) for 'tab' in libtmp.so. This does not happen in gdb-7.2 (I'm not sure why), so it finds the (incorrect) definition in libtmp.so. If I stop in main() before stopping in sub(), then gdb-7.2 resolves the address correctly. I'm looking for suggestions on how to correct this in gdb-7.2. (I don't have the option of moving to a more recent version.) I can modify gdb to recognize DW_OP_deref (I would guess in locexpr_describe_location_piece()). I can (somehow) force gdb to always read the symbols from the executable. (Anyone know if this was an intentional change or a side effect of some other patch?) Any other suggestions? -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077