On 18/08/16 19:21, Myungho Jung wrote:
I found that if the first argument of dlopen is NULL, it returns a handle
of the main program. But, this way was not working in Rump. Is it possible
to add dl library working like this to rump instead of returning NULL
pointer?
What do you specifically mean by "this"? Yes, we can add a reasonably
correct approximation of dl*(). That said, I'm wary of adding completely
bogus emulation, since if those routines are present, people (and
especially programs/configure scripts) tend to assume they work the same as
on every other platform.
I mean 'dlopen(NULL, RTLD_FIRST)' is supposed to return a handle of running
binary itself. So, if it is also possible in rump, we can just replace
dlopen("filename", flags) with dlopen(NULL, flags) though should be care
about name confliction between libraries. The problem is that dl* functions
are not in a library but in ld.so and linked in runtime in netbsd. If ld.so
can be built as static library, those ugly lookup table in my patch will be
unnecessary. I tried to extract ld.so from netbsd source in rumprun repo
but failed to build as static library because of complicated dependencies.
I'm not so sure that trying to reuse ld.so is the sane way to go. It's
a linker after all, and symbol lookup is a side-effect because the
linker needs a symbol table. Plus, you have to somehow pass the symbol
table anyway.
Alternatively, dlsym may be able to be emulated using BFD library(
https://sourceware.org/binutils/docs/bfd/). But, in this case, java binary
should be included in file system image and I also failed to build the
library in rump.
Again, I think it's better to provide the symbol table via the offline
toolchain instead of trying to parse it from the entire binary at runtime.
For example, one could leave empty space at the end of the loadable
memory, and patch the symbol table and its size there after linking.
Then, at runtime, any memory not used for the symbol table would be free
for system use.
