From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16601 invoked by alias); 13 Dec 2008 16:02:01 -0000 Received: (qmail 16347 invoked by uid 22791); 13 Dec 2008 16:02:00 -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; Sat, 13 Dec 2008 16:01:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0B1ED2A9630; Sat, 13 Dec 2008 11:01:20 -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 gTRFd5JDq2JB; Sat, 13 Dec 2008 11:01:19 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F179A2A963C; Sat, 13 Dec 2008 11:01:18 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4CAFDE7ACD; Sat, 13 Dec 2008 17:01:10 +0100 (CET) Date: Sat, 13 Dec 2008 16:02: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: <20081213160110.GF6866@adacore.com> References: <20081209013252.9E1C83A6B2E@localhost> <20081209020744.GA11173@caradoc.them.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ac60eac0812111603r68ffa49exd7cb0ce403d07310@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/msg00245.txt.bz2 > So, the choices appear to be: > > - leave GDB broken and wait for newer glibc :( I'm just realizing that this might be a very very visible problem, if most offsets are negative. Is that the case? > - do sign extension, but only for N_LSYM and N_PSYM symbols as > a heuristic. 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). After all, values for these types of symbols are always offsets to some location inside a frame, and I can't see a frame being that big. > - pre-scan the objfile to determine highest link address, and > do sign extension if that address is (well) below 0x80000000 Seems too much work, IMO. -- Joel