On Sat, Apr 19, 2025 at 01:03:15AM +0300, Andriy Gapon wrote: > > I am trying to understand if RTLD_DEEPBIND should help in the following > scenario or if I misunderstand its purpose. > > There is a program that has a parser based on lex/yacc, so there is function > yyparse in the code and global text symbol yyparse in the binary. > > The program can load shared objects (plugins) using dlopen. > > One of the plugins is linked with a shared library... actually with > libdtrace.so. > The library has its own parser (for DTrace language) and it also has yyparse > global text symbol. > > There is a problem that when the program dlopen-s the plugin and calls its > code the yyparse calls in libdtrace get resolved to the yyparse function in > the program itself, not in libdtrace. > This is, of course, not unexpected according to how dlopen works. > > However, I expected that if I add RTLD_DEEPBIND to the dlopen call that > loads the plugin then libdtrace's yyparse calls would get resolved to the > libdtrace yyparse because they all are in the same dependency subtree. > > But adding RTLD_DEEPBIND does not seem to help, libdtrace yyparse calls are > still resolved to the main binary's yyparse. Could it be that the module is linked to the main binary?
RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED object for the object where the symbol is resolved, then by looking at the global list of loaded objects. Non-deepbind resolution is performed by looking at the global list. You can see it in the rtld.c:symlook_default(). Also it might be useful to set LD_DEBUG=1 and read the debugging output from rtld. > > I should also note that the main binary does not have any dependency on > libdtrace. It comes into picture only through the plugin. > > P.S. > I think that the issue could be resolved by building libdtrace differently, > so that its yyparse is resolved at link time and is not treated as a global > symbol. > And I think that we should probably do it. > However, I am still curious if RTLD_DEEPBIND should have helped here. > > Thank you. > -- > Andriy Gapon >
