6

I'm supporting a Linux program that allows users to write their own .so file based plugins that are loaded at runtime with dlopen(). Sometimes a user will forget to include a C++ file in the makefile that contains necessary function definitions. When the plugin manager uses dlsym() to load an exported function from the plugin that depends on one of these missing function definitions, I get a null function address.

My question: How can I detect this error ahead of time? I've tried the -z defs and -Wno-undef linker flags, but they don't generate an error. I've tried the nm, readelf, and objdump commands with various flags but the undefined functions don't show up in the symbol tables at all. Any suggestions? Thanks!

noah.b
  • 93
  • 5
  • If the only references to the functions are those implicit in the use of `dlsym`, how would the linker know they’re missing? – Davis Herring Aug 28 '19 at 00:13
  • Just terminate the main program if any of these symbols cannot be found via `dlsym`. Also, if any required symbols cannot be found in the output of `nm -D plugin.so` then the plugin is broken. – Lorinczy Zsigmond Sep 02 '19 at 17:38

2 Answers2

0

i suspect the null function address is mostly the result of using some third party library in the .so file and when the linux program does dlopen(), it can not locate the third party and then null function address is returned

i suggest try nm command on both "good" and "bad" .so files and look for the pattern of symbols with ' U ' (undefined symbol) "bad" .so file would have more ' U '

see also Unresolved external symbol in object files and Linux shared library that uses a shared library undefined symbol

James Li
  • 469
  • 3
  • 7
  • The missing functions are not in a third party library. They are defined in a user created C++ file that they forgot to include in the makefile. I can't search for them using nm because the function names are not in the symbol table at all. – noah.b Aug 28 '19 at 18:34
0

--no-undefined / -z defs documentation:

Undefined symbols in shared libraries are still allowed.

Use another flag: --no-allow-shlib-undefined:

Allows or disallows undefined symbols in shared libraries. This switch is similar to --no-undefined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271