From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8910 invoked by alias); 12 Dec 2008 00:11:05 -0000 Received: (qmail 8898 invoked by uid 22791); 12 Dec 2008 00:11:05 -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; Fri, 12 Dec 2008 00:10:25 +0000 Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id mBC0AM8H021278 for ; Thu, 11 Dec 2008 16:10:22 -0800 Received: from bwz13 (bwz13.prod.google.com [10.188.26.13]) by wpaz33.hot.corp.google.com with ESMTP id mBC0AHNt012272 for ; Thu, 11 Dec 2008 16:10:18 -0800 Received: by bwz13 with SMTP id 13so4228612bwz.8 for ; Thu, 11 Dec 2008 16:10:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.171.20 with SMTP id y20mr1646582muo.19.1229040210001; Thu, 11 Dec 2008 16:03:30 -0800 (PST) In-Reply-To: <8ac60eac0812111601v20566268h6f7977c71e5b8a8f@mail.gmail.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> Date: Fri, 12 Dec 2008 00:11:00 -0000 Message-ID: <8ac60eac0812111603r68ffa49exd7cb0ce403d07310@mail.gmail.com> Subject: Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB. From: Paul Pluzhnikov To: Andreas Schwab , Joel Brobecker , 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/msg00220.txt.bz2 On Thu, Dec 11, 2008 at 12:57 AM, Andreas Schwab wrote: > Paul Pluzhnikov writes: ... >> - if (bfd_get_sign_extend_vma (abfd)) \ >> + if (sizeof (bfd_vma) > 4 || bfd_get_sign_extend_vma (abfd)) \ > > I don't think this does the right thing for genuine addresses beyond > 0x80000000. You can do that only for values that are truely signed, > which stabs has no way to express. Hmm, I guess if a STABS executable is linked at above 0x80000000, this could happen. So, the choices appear to be: - leave GDB broken and wait for newer glibc :( - do sign extension, but only for N_LSYM and N_PSYM symbols as a heuristic. - pre-scan the objfile to determine highest link address, and do sign extension if that address is (well) below 0x80000000 Suggestions? Thanks, -- Paul Pluzhnikov [Andreas, sorry for the repeat: clicked reply instead of reply-all]