This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 9 Dec 2013 12:33:33 +0100
- Subject: Re: [RFA] nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing
- Authentication-results: sourceware.org; auth=none
- References: <1386070185-8020-1-git-send-email-brobecker at adacore dot com> <529E361B dot 7070807 at redhat dot com> <20131205105437 dot GE3175 at adacore dot com> <52A073CC dot 3050009 at redhat dot com>
> :-) I'd be good to have this new info distilled as a comment
> in the code, IMO.
Excellent suggestion, of course. I, with my incessant asking for
comments, should have thought of it too! ;-)
[regarding gdbserver]
> I think the fix is very low risk, and could go in with minimal
> testing.
OK - will work on that ASAP.
> > In the meantime, does the GDB-side fix look OK to commit to you
> > (modulo the small issue you raised)?
>
> Yes.
>
> One nit -- does ntdll.dll appears at the end of the
> loaded list with this fix, or at the beginning? I'd think
> it should be the first dll in "info sharedlibrary", assuming
> that that's what we see on older Windows versions.
I think this is going to be difficult, unless we defer the notification
for the other shared libraries - in which case we're doing what I wanted
to do, but after 7.7 gets cut, which is to ignore LOAD_DLL_DEBUG_EVENTs
until the end of do_initial_windows_stuff, and then just iterate over
all modules to generate the SOs.
The reason why I think it would be difficult is because, when a new
shared object is loaded, we get a TARGET_WAITKIND_LOADED, which
I think eventually leads us to:
-> handle_solib_event ()
-> solib_add (NULL, 0, ¤t_target, auto_solib_add);
-> update_solib_list (from_tty, target);
And looking at update_solib_list, it calls current_sos, and then
adds new SOs at the end (via the VEC_push). On top of that, an
easier issue that we'll have to handle in windows-nat the adding
of the new SO at the start of the SO list, rather than then end.
Since this is mostly cosmetic and only affects Windows 2012,
I would leave it alone until we have more leeway towards simplifying
the DLL handling.
--
Joel