This is libdlbind, an extension to System V-style dynamic loaders to allow dynamic allocation of objects and dynamic binding of symbols.
Its main use-case is in JIT compilers, or other run-time code generators. Rather than allocating code memory yourself, allocating it with dlbind keeps the dynamic loader informed -- along with any debugger that might be attached. This means that your JITted code and data are debuggable "by default" just like any other dynamically loaded content. It also means that the usual dlsym() and dladdr() interfaces will work against your JITted output.
Currently, the implementation is very minimal and naive. It does work, with some caveats:
you must have a writable /run/shm directory;
no deallocation or unbinding yet;
when defining a new symbol, the dlreload() call, necessary for introducing the new symbols, requires some instrumentation of the dynamic linker or and/or modifications to the debugger. To do this introduction, the linker looks for a "change in the link map". To signal this, we have two options.
(1) really unload (unmap) and reload (re-open/mmap) the file;
(2) don't really close the file (hence keeping the mappings in memory), but make the debugger re-read the symbols anyway.
To make (2) work, we need to make the debugger think that the link map has changed even when it hasn't, i.e. to be more conservative and (correctly) avoid assuming that an unchanged link map means unchanged symbol tables. This is probably the "right way" but means extending the protocol between dynamic linker and debugger. This is not done yet.
Fortunately we can make (1) work already. The main caveat is that we rely on getting the same object base address when we do the re-load... currently this seems to work on glibc's ld.so. To ensure data written to the file persists across close/reopen, we also require (logically) a modified dynamic linker, so that the mmap() calls it makes for libdlbind objects request MAP_SHARED rather than MAP_PRIVATE semantics. As a quick-and-dirty solution, we can trap these syscalls and tweak the flags. This is what our gdb-script <test/elfproto-simple/gdb-script> does, as a minimal demo of correct operation. In liballocs https://github.com/stephenrkell/liballocs/, the same idea is used but the syscall trapping is automated and happens online. Medium-term, a modified dynamic linker created with libgerald https://github.com/stephenrkell/libgerald/ will be a more robust solution... most readily for tweaking the mmap flags, but also allowing us to implement the RTLD_RELOADABLE extension mentioned above.