Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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