From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12294 invoked by alias); 9 Dec 2008 02:43:32 -0000 Received: (qmail 12176 invoked by uid 22791); 9 Dec 2008 02:43:32 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Dec 2008 02:42:57 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id mB92gtu8007019 for ; Mon, 8 Dec 2008 18:42:55 -0800 Received: from ug-out-1314.google.com (ugfj3.prod.google.com [10.66.186.3]) by zps19.corp.google.com with ESMTP id mB92grWT012369 for ; Mon, 8 Dec 2008 18:42:53 -0800 Received: by ug-out-1314.google.com with SMTP id j3so754637ugf.3 for ; Mon, 08 Dec 2008 18:42:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.172.7 with SMTP id z7mr1515256muo.15.1228790572892; Mon, 08 Dec 2008 18:42:52 -0800 (PST) In-Reply-To: <20081209020744.GA11173@caradoc.them.org> References: <20081209013252.9E1C83A6B2E@localhost> <20081209020744.GA11173@caradoc.them.org> Date: Tue, 09 Dec 2008 02:43:00 -0000 Message-ID: <8ac60eac0812081842l6ac5344fw2fd57011d3dfef42@mail.gmail.com> Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. From: Paul Pluzhnikov To: Paul Pluzhnikov , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-12/txt/msg00164.txt.bz2 On Mon, Dec 8, 2008 at 6:07 PM, Daniel Jacobowitz wrote: >> We end up with an impossible target address of 0x1ffffbf88. > > Conclusion doesn't follow from example Well, that's the value I observed in the debugger... > Do you mean that SYMBOL_VALUE is -16U or -16UL, and > that's where the wrapping comes from? But SYMBOL_VALUE is a long, > signed. Is SYMBOL_VALUE (long) 0xfffffff0? Yes: (top) p *var $1 = {ginfo = {name = 0x16feaa0 "ar_ptr", value = {ivalue = 4294967280, block = 0xfffffff0, bytes = 0xfffffff0
, address = 4294967280, chain = 0xfffffff0}, language_specific = {cplus_specific = { demangled_name = 0x0}}, language = language_c, section = 0, obj_section = 0x0}, type = 0x16fe418, symtab = 0x1702900, domain = VAR_DOMAIN, aclass = LOC_ARG, is_argument = 1, line = 2742, ops = 0x0, aux_value = 0x0, hash_next = 0x0} That value was set here: #0 define_symbol (valu=4294967280, string=0x2aaaabd3285c "ar_ptr:p(0,32)", desc=2742, type=160, objfile=0xed4070) at ../../src/gdb/stabsread.c:936 #1 0x0000000000545f98 in process_one_symbol (type=160, desc=2742, valu=4294967280, name=0x2aaaabd3285c "ar_ptr:p(0,32)", section_offsets=0xe9bcf0, objfile=0xed4070) at ../../src/gdb/dbxread.c:3178 #2 0x0000000000545001 in read_ofile_symtab (pst=0xf9cde8) at ../../src/gdb/dbxread.c:2600 ... And that (AFAICT) is coming from BFD. So it appears that BFD gives us 0x00000000fffffff0, but GDB expects 0xfffffffffffffff0 > If that's the case then the debug reader might be to blame. This is coming from a rather old glibc-2.2.2, compiled with non-exstent :) old compiler: GNU CC version 2.96 20000731 (Red Hat Linux 7.1 2.96-79). Here is what 'objdump -g /lib/i686/libc.so.6' has to say: static mchunkptr chunk_alloc (arena *ar_ptr /* 0x00000000fffffff0 */, size_t nb /* 0x00000000ffffffec */) { /* 0x000000000007f2f0 */ { /* 0x000000000007f2f0 */ register mbinptr q /* 0x0000000000000002 */; register mchunkptr bck /* 0x0000000000000007 */; ... And here is 'objdump --stabs': 105431 FUN 0 2746 0007f2f0 317480 chunk_alloc:f(0,25) 105432 PSYM 0 2742 fffffff0 317500 ar_ptr:p(0,32) 105433 PSYM 0 2742 ffffffec 317515 nb:p(3,2) -- Paul Pluzhnikov