[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/1] plugins: Move the windows linking function to qemu
|
From: |
Greg Manning |
|
Subject: |
Re: [PATCH v2 1/1] plugins: Move the windows linking function to qemu |
|
Date: |
Fri, 10 Nov 2023 17:36:41 +0000 |
> Previously, a plugin author needed an implementation of the
> __pfnDliFailureHook2 or __pfnDliNotifyHook2 hook in the plugin. Now all
> they need is a null exported pointer with the right name (as in
> win32_linker.c). If QEMU finds this, it will set it to the hook
> function, which has now moved into qemu (os-win32.c).
I have a new idea for this. We've made the qemu_plugin_api.lib file which
is a delaylib with all the symbol names of all the api functions, so windows
can do the whole delay-linking thing. We could also put into that archive
the object win32_linker.o:
ar -q qemu_plugin.api.lib ../whatever/win32_linker.o
Then hopefully when a plugin links to this, it gets the __pfnDliFailureHook2
symbol defined and set up and everything would work. Except gcc strips
out any unreferenced symbols from static libs when linking. So the plugin
would have to be linked thusly:
gcc -shared -o my_plugin.dll -Wl,-u,__pfnDliFailureHook2 my_plugin.o
qemu_plugin_api.lib
But no other qemu-fiddling-with-things or extra code in plugins required.
Hmm. Feels like half a solution. I wonder if there's a way to mark symbols as
"always required despite what dead code analysis says".
Greg.