Identifying dependencies used via dlopen()

Posted Apr 24, 2024 9:29 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Identifying dependencies used via dlopen() by ScottMinster
Parent article: Identifying dependencies used via dlopen()

The code doing the loading can call a void * plugin_init(void) function, which does whatever your deferred dynamic initializers do today; call back to the opener to register a file format reader, a new renderer, a writer, whatever else they currently do at the moment they're loaded. At exit, it can call a void plugin_destroy(void * init_return) function, which does the destruction before the plugin is unloaded.

There's nothing that can be done via code running at load time that can't also be done via calling a function inside the library; the reason most psABIs run code at load time, rather than simply expecting that the start point runs constructors etc, is to make it easy to implement C++ deferred dynamic initialization.

If I were interested in playing with psABIs, with a view to producing an alternative to current ELF mechanisms, I'd be tempted to experiment with indirect symbol resolution as an alternative to running code on load; the idea is that when a symbol is resolved, instead of the loader looking up the symbol value directly (as it does normally), it would run code that provides the symbol value or a reference to another symbol to look up. You can then implement deferred dynamic initialization by having indirect lookup functions that check a flag, run static initializers if needed, and return the "real" symbol to the loader for it to look up - slightly slowing down symbol lookup if static initializers exist, but deferring it to the last moment that C++ permits.