From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6871 invoked by alias); 7 Mar 2008 19:40:46 -0000 Received: (qmail 6863 invoked by uid 22791); 7 Mar 2008 19:40:46 -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.31) with ESMTP; Fri, 07 Mar 2008 19:39:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D52092AA298 for ; Fri, 7 Mar 2008 14:39:42 -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 RVqZc-Ky-vkn for ; Fri, 7 Mar 2008 14:39:42 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 939762AA273 for ; Fri, 7 Mar 2008 14:39:42 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 58FD6E7ACB; Fri, 7 Mar 2008 11:39:40 -0800 (PST) Date: Fri, 07 Mar 2008 19:40:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA] "continue" after "attach" fails on sparc64-solaris Message-ID: <20080307193940.GC3892@adacore.com> References: <20080201181237.GA20356@adacore.com> <20080307184121.GB3892@adacore.com> <20080307191140.GA368@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080307191140.GA368@caradoc.them.org> 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-03/txt/msg00056.txt.bz2 > If anything I think you're underabusing them - we asked you to be a > global maintainer because we trusted your judgement :-) OK! :) > > > I fixed the problem by implementing a suggestion to use the AT_BASE > > > attributed, but as it turns out, this was only good enough for sparc32. > > > As far as I can tell, the auxilliary data obtained when running a 64bit > > > app looks screwed. So we still have the same problem on sparc64. > > This was what threw me off an immediate reply. I doubt the kernel's > got a bug like this, since Solaris tools use the auxv data. So we > must have an error when reading it. Maybe the format is different > than we expect (32-bit vs 64-bit fields)? It's been a while, but I remember inspecting the memory contents of what was supposed to be the AUXV region, and couldn't make any sense out of it at the time, even after trying to change sizes to 32bit or 64bit. If I get a chance, I'll look at it again. > Otherwise the patch looks fine. Thanks! I checked it in. -- Joel