Re: [RFA] nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing

Joel Brobecker
2013-12-09T11:33:44Z

> :-) 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, &current_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