OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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.
This commit is contained in:
Joel Brobecker 2014-02-20 17:18:47 +01:00
parent 957d095533
commit 3be75f87b9
2 changed files with 29 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
gdb/ChangeLog
View File

@ -1,3 +1,10 @@
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.

23
gdb/windows-nat.c
View File

@ -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;