On 2/13/20 4:46 PM, Eric Blake wrote:
Instead, we can fix the problem by relying on the fact that Linux
provides dlmopen(), which opens a shared library in a new namespace.
We first load a shim library into this namespace which overrides the
dlopen() present in the main executable, then load the VDDK library.
All further dlopen() calls made during VDDK initialization now go
through our shim, at which point we can rewrite them to be absolute
calls before the real dlopen() kicks in.
Note this may break some callers who are not using libdir and
expecting LD_LIBRARY_PATH to work, so it's a change in behaviour which
we will have to highlight prominently in the 1.18 release notes.
Thanks: Dan Berrangé, Ming Xie, Eric Blake.
[eblake: Heavy modifications to Rich's initial patch, including
the idea of a shim library]
---
Replaces patches 2-3/3 of v2, but keeps 1/3 of that series applied as-is.
Passes 'make check' for me, although we might still need a tweak for
how to resolve "nbdkit-shim-dlopen.so" from its installed location.
I don't have VDDK installed locally, so I can't guarantee how this
works with the REAL vddk library, but the fact that 'make check'
passes proves that I got the dlmopen() stuff working correctly.
One other depressing note:
https://sourceware.org/bugzilla/show_bug.cgi?id=15971
https://sourceware.org/bugzilla/show_bug.cgi?id=11839
Both gdb and glibc need patches applied before you can debug anything
loaded via dlmopen(); ideas for patches were last discussed 7 years ago,
but still nothing has landed.
We're unlikely to need gdb debugging of vddk code itself (after all,
it's already a proprietary library, so you can't follow along with
source code), but the lack of debuggability of the shim code makes
maintenance that much harder (it already cost me some time today when I
had to frequently recompile and resort to printf debugging) - if we
decide to go with a patch along these lines, we'd better be sure it is
robust enough to not need to be inspecting the code in gdb any time soon.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org