Re: [Qemu-devel] RFC: DSO (dynamic shared objects) support

[Laszlo Ersek]

On 06/18/13 13:37, Michael Tokarev wrote:

> First of all, we need a global config switch/check for this kind of
> service.  On a POSIX system this should make the executable to be
> linked with -rdynamic option, in order to make all symbols in the
> executable to be available to plugins.
> 
> This is an interesting case.  We may end up in some symbols from
> qemu libraries not linked in when building the executable, but
> that symbol may be used in some plugin.  Such situations, if will
> happen, will need to be deal with on a case-by-case basis somehow.

       -rdynamic
           Pass the flag -export-dynamic to the ELF linker, on
           targets that support it. This instructs the linker to
           add all symbols, not only used ones, to the dynamic
           symbol table. This option is needed for some uses of
           "dlopen" or to allow obtaining backtraces from within
           a program.

I think the problem you describe doesn't threaten therefore. OTOH link
time and executable size could easily grow.


> Next, the executable should be linked with -ldl (again, for a POSIX
> system), to be able to dynamically load anything.  This goes on the
> same line as -rdynamic -- once we enable plugins, both linker options
> are enabled.
> 
> 
> Next, the module loading support.  On POSIX it is <dlfcn.h> and
> dlopen(3), this one is trivial.

dlopen(), yes, dlsym(), yes; type-casting the dlsym()-returned (void*)
to the correct function pointer type, or the pointer-to-struct type,
where the struct has a bunch of function pointers: not so trivial; some
new type declarations would be necessary.


> I think the best is to hook up into util/module.c.  Currently,
> we explicitly call modue_call_init(type) for module types the
> executable is interested with.  So in that call we may also
> load all plugins of the given type just before running all the
> module init functions.
> 
> For modules themselves, nothing changes -- __attribute__((constructor))
> does the same thing be it in a DSO or statically linked into
> executable.

Ah. Basically, you wouldn't use dlsym() at all -- modules would register
their stuff in their constructors, and the main executable would search
by name?


> +        if (dlopen(path, RTLD_NOW) == NULL)

For inter-module sybmol resolution (motivated by any functional
dependencies, of course), RTLD_GLOBAL would be needed too (and then of
course order of loading would matter).


> +        {
> +            fprintf(stderr, "warning: unable to load plugin %s\n", path);

dlerror() is standard, and it provides very good error messages on
GNU/Linux.

Laszlo