Do you know any library or project related to this? Thanks
On Fri, Aug 19, 2016 at 5:51 AM, Antti Kantee <[email protected]> wrote: > 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. > >
