From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1337 invoked by alias); 11 Feb 2010 11:22:14 -0000 Received: (qmail 1326 invoked by uid 22791); 11 Feb 2010 11:22:12 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 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; Thu, 11 Feb 2010 11:22:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 698652BAC22 for ; Thu, 11 Feb 2010 06:22:05 -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 2WV2V+AZfz8j for ; Thu, 11 Feb 2010 06:22:05 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D6C582BAC02 for ; Thu, 11 Feb 2010 06:22:04 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 40DD2F59AE; Thu, 11 Feb 2010 15:21:57 +0400 (RET) Date: Thu, 11 Feb 2010 11:22:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA/windows] Spurious "dll not found" error messages on x64-windows. Message-ID: <20100211112157.GD2907@adacore.com> References: <1265256768-30183-1-git-send-email-brobecker@adacore.com> <20100204221752.GA27209@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline In-Reply-To: <20100204221752.GA27209@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-02/txt/msg00282.txt.bz2 --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1516 > Sorry but, I don't think this right. What's the point of issuing the > error after inferior startup? I think it's only during startup that > something like this would be useful. > > I think making the error a complaint makes more sense. Sure. I am not sure when DLLs are unloaded most... I was thinking more about the case where a user does a LoadLibrary/FreeLibrary. Regardless, here is a version that transforms the error into a complaint. So far, complaints appears to be used only for symbol file events. It's a tiny bit of a strech to include our complaint in that category, but I think that creating a different category for that might be a bit overkill. I don't mind doing so, however. I chose the simpler approach for now, which gives us the following complaint when they are activated: [New Thread 94404.0x222a8] During symbol reading, dll starting at 0x77a60000 not found.. During symbol reading, dll starting at 0x77650000 not found.. [...] The "During symbol reading" is where the complaint category comes in play. Note that the module description in complaints.h says: Definitions for complaint handling during symbol reading in GDB. But I don't see why this couldn't be used for other purposes (and hence why we couldn't create new categories if necessary). gdb/ChangeLog: * windows-nat.c: Add include of complaints.h. (handle_unload_dll): Change dll-not-found error into a complaint. Tested on x86_64-windows with an x86-windows toolchain. -- Joel --WhfpMioaduB5tiZL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="unloaded-dll-not-found.diff" Content-length: 1146 --- windows-nat.c.orig 2010-02-11 12:09:23.911442400 +0100 +++ windows-nat.c 2010-02-11 11:22:29.060598600 +0100 @@ -64,6 +64,7 @@ #include "windows-tdep.h" #include "windows-nat.h" #include "i386-nat.h" +#include "complaints.h" #define AdjustTokenPrivileges dyn_AdjustTokenPrivileges #define DebugActiveProcessStop dyn_DebugActiveProcessStop @@ -783,8 +784,15 @@ handle_unload_dll (void *dummy) return 1; } - error (_("Error: dll starting at %s not found."), - host_address_to_string (lpBaseOfDll)); + /* We did not find any DLL that was previously loaded at this address, + so register a complaint. We do not report an error, because we have + observed that this may be happening under some circumstances. For + instance, running 32bit applications on x64 Windows causes us to receive + 4 mysterious UNLOAD_DLL_DEBUG_EVENTs during the startup phase (these + events are apparently caused by the WOW layer, the interface between + 32bit and 64bit worlds). */ + complaint (&symfile_complaints, _("dll starting at %s not found."), + host_address_to_string (lpBaseOfDll)); return 0; } --WhfpMioaduB5tiZL--