summaryrefslogtreecommitdiff
path: root/gdb/windows-nat.c
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2014-02-20 17:18:47 +0100
committerJoel Brobecker <brobecker@adacore.com>2014-02-20 17:21:50 +0100
commit3be75f87b9a0e5b06175dadedb268c609609c821 (patch)
tree285440cdad3d97362659e4d1844d24f40f99637e /gdb/windows-nat.c
parent957d095533afd835969b8cf8e86adfa63bfb874c (diff)
downloadbinutils-gdb-3be75f87b9a0e5b06175dadedb268c609609c821.tar.gz
windows-nat.c: Bring comment back regarding handling of DLL load events.
This patch brings back a comment that got stripped down a bit too much during a recent change. gdb/ChangeLog: * windows-nat.c (handle_unload_dll): Add function documentation. (do_initial_windows_stuff): Add comment explaining why we wait until after inferior initialization has finished before processing all DLLs.
Diffstat (limited to 'gdb/windows-nat.c')
-rw-r--r--gdb/windows-nat.c23
1 files changed, 22 insertions, 1 deletions
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index a570a1a210d..4366aab64b1 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -802,6 +802,14 @@ windows_free_so (struct so_list *so)
xfree (so);
}
+/* Handle a DLL unload event.
+ Return 1 if successful, or zero otherwise.
+
+ This function assumes that this event did not occur during inferior
+ initialization, where their event info may be incomplete (see
+ do_initial_windows_stuff and windows_add_all_dlls for more info
+ on how we handle DLL loading during that phase). */
+
static int
handle_unload_dll (void *dummy)
{
@@ -1735,7 +1743,20 @@ do_initial_windows_stuff (struct target_ops *ops, DWORD pid, int attaching)
}
/* Now that the inferior has been started and all DLLs have been mapped,
- we can iterate over all DLLs and load them in. */
+ we can iterate over all DLLs and load them in.
+
+ We avoid doing it any earlier because, on certain versions of Windows,
+ LOAD_DLL_DEBUG_EVENTs are sometimes not complete. In particular,
+ we have seen on Windows 8.1 that the ntdll.dll load event does not
+ include the DLL name, preventing us from creating an associated SO.
+ A possible explanation is that ntdll.dll might be mapped before
+ the SO info gets created by the Windows system -- ntdll.dll is
+ the first DLL to be reported via LOAD_DLL_DEBUG_EVENT and other DLLs
+ do not seem to suffer from that problem.
+
+ Rather than try to work around this sort of issue, it is much
+ simpler to just ignore DLL load/unload events during the startup
+ phase, and then process them all in one batch now. */
windows_add_all_dlls ();
windows_initialization_done = 1;