This is the mail archive of the
mailing list for the GDB project.
[RFA] Fix DLL unload events in MinGW GDB
- From: Eli Zaretskii <eliz at gnu dot org>
- To: gdb-patches at sourceware dot org
- Date: Sun, 19 May 2013 21:39:03 +0300
- Subject: [RFA] Fix DLL unload events in MinGW GDB
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
I found out today that MinGW GDB cannot announce DLL unloads
correctly, with both stop-on-solib-events turned on and with "catch
unload". It says this instead:
Stopped due to shared library event (no libraries added or removed)
Debugging GDB, I see the following sequence:
. when a DLL is unloaded, handle_unload_dll is called by
windows-nat.c, and correctly finds the DLL that is being unloaded.
. handle_unload_dll then calls solib_add, which puts the unloaded
DLL on the deleted_solibs list of the current_program_space.
. I put a watchpoint on the deleted_solibs list, and I see that at
some point after handle_unload_dll returns, we call
handle_solib_event, which begins by calling
clear_program_space_solib_cache, which empties the deleted_solibs
list. It then calls solib_add again, but now it's too late.
So it looks like the call to solib_add inside handle_unload_dll is the
culprit. And indeed, the trivial one-liner below is enough to fix
both stop-on-solib-events and "catch unload" for me.
OK to commit (with ChangeLog)? Branch also?
--- gdb/windows-nat.c~1 2013-04-27 11:58:26.875375000 +0300
+++ gdb/windows-nat.c 2013-05-19 21:34:31.500000000 +0300
@@ -890,7 +890,6 @@ handle_unload_dll (void *dummy)
DEBUG_EVENTS (("gdb: Unloading dll \"%s\".\n", sodel->so_name));
- solib_add (NULL, 0, NULL, auto_solib_add);