From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5012 invoked by alias); 9 Dec 2008 11:30:40 -0000 Received: (qmail 4946 invoked by uid 22791); 9 Dec 2008 11:30:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 09 Dec 2008 11:29:58 +0000 Received: (qmail invoked by alias); 09 Dec 2008 11:29:55 -0000 Received: from p3E9E6EA3.dip.t-dialin.net (EHLO licht.localdomain) [62.158.110.163] by mail.gmx.net (mp060) with SMTP; 09 Dec 2008 12:29:55 +0100 X-Authenticated: #25218368 Received: from licht.localdomain (localhost.localdomain [127.0.0.1]) by licht.localdomain (8.12.8/8.12.8) with ESMTP id mB9BTqoP010140; Tue, 9 Dec 2008 12:29:52 +0100 Received: (from pes@localhost) by licht.localdomain (8.12.8/8.12.8/Submit) id mB9BTqPU010137; Tue, 9 Dec 2008 12:29:52 +0100 From: Peter Schauer Message-Id: <200812091129.mB9BTqPU010137@licht.localdomain> Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. To: ppluzhnikov@google.com (Paul Pluzhnikov) Date: Tue, 09 Dec 2008 11:30:00 -0000 Cc: gdb-patches@sourceware.org In-Reply-To: <8ac60eac0812081842l6ac5344fw2fd57011d3dfef42@mail.gmail.com> from "Paul Pluzhnikov" at Dec 08, 2008 06:42:52 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.42 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/msg00170.txt.bz2 I had the same problem a very long time ago when trying to debug 32 bit stabs executables with a sparc Solaris 64 bit GDB. I came up with the following local hack, but didn't dare to RFA it back then, as it didn't look clean enough. We abandoned sparc Solaris development later on and were no longer interested in a proper fix. *** ./stabsread.c.orig Sat Jul 20 11:51:50 2002 --- ./stabsread.c Sun Jul 28 10:43:45 2002 *************** *** 927,932 **** --- 927,935 ---- case 'l': SYMBOL_TYPE (sym) = read_type (&p, objfile); SYMBOL_CLASS (sym) = LOC_LOCAL; + /* Sign extend value for 64x32 GDB. */ + if ((sizeof (CORE_ADDR) > 4) && ((valu & ~0x7fffffff) == 0x80000000)) + valu = (valu ^ 0x80000000) - 0x80000000; SYMBOL_VALUE (sym) = valu; SYMBOL_DOMAIN (sym) = VAR_DOMAIN; add_symbol_to_list (sym, &local_symbols); *************** *** 947,952 **** --- 950,958 ---- SYMBOL_TYPE (sym) = read_type (&p, objfile); SYMBOL_CLASS (sym) = LOC_ARG; + /* Sign extend value for 64x32 GDB. */ + if ((sizeof (CORE_ADDR) > 4) && ((valu & ~0x7fffffff) == 0x80000000)) + valu = (valu ^ 0x80000000) - 0x80000000; SYMBOL_VALUE (sym) = valu; SYMBOL_DOMAIN (sym) = VAR_DOMAIN; add_symbol_to_list (sym, &local_symbols); > 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 > -- Peter Schauer Peter.Schauer@mytum.de