From 3be75f87b9a0e5b06175dadedb268c609609c821 Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Thu, 20 Feb 2014 17:18:47 +0100 Subject: 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. --- gdb/windows-nat.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) (limited to 'gdb/windows-nat.c') diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c index a570a1a..4366aab 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; -- cgit v1.1