[PATCH] D80059: [ELF] Parse SHT_GNU_verneed and respect versioned undefined symbols in shared objects

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 18 05:52:40 PDT 2020


psmith added a comment.

Just thinking if it would be possible to resolve this without having to read the verneed section of shared objects. I've not checked to see if this would make a simpler implementation though.

> If a versioned symbol referenced by a shared object is defined in the executable, we will fail to export it.
>  If a versioned symbol referenced by a shared object in another object file, --no-allow-shlib-undefined may spuriously report an "undefined reference to " error. See https://bugs.llvm.org/show_bug.cgi?id=44842 (Linking -lfftw3 -lm on Arch Linux can cause undefined reference to __log_finite)

Reading through https://www.akkadia.org/drepper/symbol-versioning I'm not sure if a versioned symbol being defined by the application is in the spirit of the specification. As I understand it when linking an undefined reference the static linker only binds against the default version, this is then recorded as the version needed. I'm trying to work out if there is ever a case where we could create a shared object that could depend on a versioned definition in an executable as we wouldn't have the symbols from the executable when we create the shared library to record the version needed. I guess matching versioned definitions in the application could be used to preempt/intercept a version defined by a shared library, but that is about all I can think of. Do other linker's and dynamic loaders support this use case?

For a versioned symbol referenced by a shared object, that is defined in another shared object in the link, for the purposes of no-allow-shlib-undefined it could be possible with some loss of accuracy, to resolve it as defined if there were any versioned symbol definitions. This would miss the case where the versions don't match, but this would be diagnosed by the Dynamic Loader, however it wouldn't error for a reference to __log_finite from a shared library to __log_finite at GLIBC_2.15


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80059/new/

https://reviews.llvm.org/D80059





More information about the llvm-commits mailing list