Re: [PATCH 14/22] plugins: make test/example plugins work on windows

[Greg Manning]

> > A bit more important: would it make sense to include the hook *in the
> > QEMU executable itself*, rather than in the DLL?  If it works, it would
> > be much preferrable.  You still would have to add the .lib file to the
> > compilation, but win32_linker.c could simply be placed in os-win32.c
> > with fewer changes to meson.build and the makefiles.

> My initial trials of this didn't work. But having read the docs again, I'm
> going to have another go at it now...

Here is a diagram of what's going on.

  /---dynamic load------v
qemu               libplugin.dll
  ^---delay load--------/

First, qemu dynamically loads the plugin, which does no linking. It finds
the function qemu_plugin_install, and invokes it. As soon as libplugin.dll
calls any qemu_plugin_* function, the delay loader steps in and searches for
qemu.exe. It fails to find it, and the delay failure helper steps in and
returns the right reference to the top level executable. Everything gets
linked OK.

Windows will look for __pfnDliFailureHook2 in the module doing the delay
loading, which in this case is the plugin DLL. So, the __pfnDliFailureHook2
function pointer needs to be in the plugin DLL. We could have qemu set the
value of that pointer before it calls install, but I can't find the way to
expose a function pointer in such a way that `g_module_symbol` can find it.
Possibly we could pass in a pointer to it in qemu_plugin_install or a new
qemu_plugin_set_linker_fn, but that is getting back to the sort of
shenanigans we're trying to avoid, and which previous attempts at windows
plugins were based on.

so: maybe, but I'm not sure it would be any tidier.

Greg.
--

Follow Rapita Systems on 
LinkedIn<https://www.linkedin.com/company/rapita-systems?utm_source=rs_email_sig>