From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29345 invoked by alias); 15 Dec 2008 08:59:18 -0000 Received: (qmail 29330 invoked by uid 22791); 15 Dec 2008 08:59:18 -0000 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, 15 Dec 2008 08:58:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0DCA92A9663; Mon, 15 Dec 2008 03:58:41 -0500 (EST) 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 lJCirkzTx8YF; Mon, 15 Dec 2008 03:58:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2AD7B2A962D; Mon, 15 Dec 2008 03:58:40 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 1C075E7ACD; Mon, 15 Dec 2008 09:58:33 +0100 (CET) Date: Mon, 15 Dec 2008 08:59:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. Message-ID: <20081215085833.GL6866@adacore.com> References: <8ac60eac0812081842l6ac5344fw2fd57011d3dfef42@mail.gmail.com> <20081209133408.GA16288@caradoc.them.org> <20081210111322.GC20054@adacore.com> <8ac60eac0812100758i586c66eak533680a6eb07459c@mail.gmail.com> <8ac60eac0812101520x76366795ieea6afb6d48fb129@mail.gmail.com> <8ac60eac0812111601v20566268h6f7977c71e5b8a8f@mail.gmail.com> <8ac60eac0812111603r68ffa49exd7cb0ce403d07310@mail.gmail.com> <20081213160110.GF6866@adacore.com> <8ac60eac0812131017l6eec4bf9r1a9fedf3e68bc6bb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0812131017l6eec4bf9r1a9fedf3e68bc6bb@mail.gmail.com> User-Agent: Mutt/1.4.2.2i 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/msg00273.txt.bz2 > > It seems to me that this should work without negative effect > > (we have to be a little careful because there is a 64bit stabs > > extension on Tru64). > > AFAICT, Tru64 goes through ECOFF reader in mdebugread.c, and so > wouldn't be affected by a change to dbxread.c You're probably right. I'm a little fuzzy now about what each module does and I'm a little tied up to investigate further. Regardless, I think that this won't affect Tru64 anyway. > 2008-12-12 Paul Pluzhnikov > > * dbxread.c (read_ofile_symtab): Sign-extend 32-bit N_LSYM and > N_PSYM STABS values for 64-bit GDB. This looks reasonable to me, but I'd really like to have a more detailed comment: > + if (sizeof (nlist.n_value) > 4 > + && (type == N_LSYM || type == N_PSYM)) > + /* These are very likely to be 32-bit negative. > + Sign-extend them for 64-bit GDB. */ > + nlist.n_value = (nlist.n_value ^ 0x80000000) - 0x80000000; In particular: . Why are we testing the size of nlist.n_value? (to detect that we are using a 64bit debugger) . You mention that this is very likely to be 32-bit negative, but offsets on some platforms may be positive. I'd like to see the comment detail a little the situation that we are trying to solve (64bit gdb debugging a 32bit app). Just as a starting point, I suggest for instance: if (sizeof (nlist.n_value) > 4) /* We are a 64bit debugger debugging a 32bit program. We have to be a little careful with the n_value in the case of N_LSYM and N_PSYM entries, because they are signed offsets that we actually read as an unsigned 32bit value. This is not a problem with 32bit debuggers where negative values end up being interpreted correctly. But we need to sign-extend the sign bit on 64bit debuggers. Otherwise, we'll end up interpreting negative values as very large positive values... */ if (type == N_LSYM || type == N_PSYM) nlist.n_value = (nlist.n_value ^ 0x80000000) - 0x80000000; -- Joel