diff options
| -rw-r--r-- | gdb/ChangeLog | 7 | ||||
| -rw-r--r-- | gdb/windows-nat.c | 23 |
2 files changed, 29 insertions, 1 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 2745653..bbb1039 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,12 @@ 2014-02-20 Joel Brobecker <brobecker@adacore.com> + * 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. + +2014-02-20 Joel Brobecker <brobecker@adacore.com> + * windows-nat.c (get_module_name): Delete. (windows_get_exec_module_filename): New function, mostly inspired from get_module_name. 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; |