From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17641 invoked by alias); 13 Jun 2007 09:31:49 -0000 Received: (qmail 17630 invoked by uid 22791); 13 Jun 2007 09:31:48 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Jun 2007 09:31:46 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 85F7C48CE79; Wed, 13 Jun 2007 05:31:44 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10433-01-6; Wed, 13 Jun 2007 05:31:44 -0400 (EDT) Received: from joel.gnat.com (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 1D2ED48CC06; Wed, 13 Jun 2007 05:31:44 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5B491E7B4F; Wed, 13 Jun 2007 02:33:13 -0700 (PDT) Date: Wed, 13 Jun 2007 09:31:00 -0000 From: Joel Brobecker To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [win32] wrong solib from/to addresses Message-ID: <20070613093313.GA6426@adacore.com> References: <20070612204900.GA4435@adacore.com> <466F2D27.9000107@portugalmail.pt> <20070613022150.GA12337@ednor.casa1.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070613022150.GA12337@ednor.casa1.cgf.cx> 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: 2007-06/txt/msg00217.txt.bz2 > > I had a similar patch here, that I dumped in favor of a rewrite > > of win32 solibs on top of Daniel's pending solib-target.c. > > That sounds like the right way to go to me. Can we hold of on this > until Daniel's changes are in? As far as I'm concerned, I'm happy to withdraw this patch. I don't think that the consequences of these wrong addresses are that bad, so there is certainly no huge hurry. At the AdaCore level, we have a tiny local change in the x86 unwinder where we decided to take a different choice than Mark did, and that choice involves a heuristic that needs to determine whether we're in a DLL or not. So this patch is a bit more urgent for us, but we have it installed in our local tree, so we're good to go. As far as the FSF tree is concerned, apart from the fact that the addresses are wrong when the users asks for that information, the only other visible symptom is a minor error in the backtrace. For frames that involve a DLL symbol, the name of the DLL where this symbol comes from can be either printed wrong, or not printed at all. I had never noticed this until I hit this issue with our local patch when testing on Vista. So patch withdrawn for now, and the puck moves to Daniel and Pedro. -- Joel