From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
To: gdb-patches@sourceware.org, Joel Brobecker <brobecker@adacore.com>
Subject: Re: [RFA/windows] Spurious "dll not found" error messages on x64-windows.
Date: Thu, 04 Feb 2010 22:18:00 -0000 [thread overview]
Message-ID: <20100204221752.GA27209@ednor.casa.cgf.cx> (raw)
In-Reply-To: <1265256768-30183-1-git-send-email-brobecker@adacore.com>
On Thu, Feb 04, 2010 at 08:12:48AM +0400, Joel Brobecker wrote:
>When running 32bit programs on x64 windows, GDB produces the following
>error messages:
>
> (gdb) start
> Temporary breakpoint 1 at 0x4015ae: file simple_main.adb, line 4.
> Starting program: C:\[...]/simple_main.exe
> [New Thread 31464.0x8cd4]
> !!! -> Error: dll starting at 0x77a60000 not found.
> !!! -> Error: dll starting at 0x77650000 not found.
> !!! -> Error: dll starting at 0x77a60000 not found.
> !!! -> Error: dll starting at 0x77990000 not found.
>
> Temporary breakpoint 1, simple_main () at simple_main.adb:4
> 4 simple.test_simple;
>
>This is something that was already discussed previously for gdbserver,
>where these events were not well handled and eventually lead to a crash:
> http://www.sourceware.org/ml/gdb-patches/2010-02/msg00011.html
>
>A quick investigation showed that there were no dll-load-events that
>correspond to these base addresses. A search on the net points at
>the WOW layer which interfaces between the 32bit and 64bit worlds.
>
>My first proposal is to silently ignore these spurious events during
>the startup phase. We could probably refine this check by also verifying
>that we are running a 32bit exe on 64bit Windows. But given that this
>error did not trigger in the past, I think that'd be overkill. In fact,
>I don't think that ditching the error would be a big loss (we could turn
>it into a complaint if we want to be able to see it in special occasions).
>
>gdb/ChangeLog:
>
> * windows-nat.c (handle_unload_dll): Disable unknown-dll error
> during the inferior startup phase.
>
>Tested on x86_64-windows using a x86-windows compiler/debugger.
>OK to apply?
>
>Thanks,
>--
>Joel
>
>---
>diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
>index 2740366..4c2d1d8 100644
>--- a/gdb/windows-nat.c
>+++ b/gdb/windows-nat.c
>@@ -783,7 +783,16 @@ handle_unload_dll (void *dummy)
> return 1;
> }
>
>- error (_("Error: dll starting at %s not found."),
>+ /* We did not find any DLL that was previously loaded at this address.
>+ This is normally an error. However, we have observed that 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 (this is the interface between
>+ the 32bit and 64bit worlds). Because of these events, we only report
>+ the error after the initialization phase is complete (there is not
>+ much data that we can use to identify these spurious events). */
>+ if (windows_initialization_done)
>+ error (_("Error: dll starting at %s not found."),
> host_address_to_string (lpBaseOfDll));
>
> return 0;
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.
cgf
next prev parent reply other threads:[~2010-02-04 22:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 4:13 Joel Brobecker
2010-02-04 22:18 ` Christopher Faylor [this message]
2010-02-11 11:22 ` Joel Brobecker
2010-02-11 17:24 ` Christopher Faylor
2010-02-12 4:55 ` Joel Brobecker
2010-02-11 19:53 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100204221752.GA27209@ednor.casa.cgf.cx \
--to=cgf-use-the-mailinglist-please@sourceware.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox