Debugging visibility of .so symbols

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Debugging visibility of .so symbols

David Zarzycki via cfe-dev
Hi,
 
I am looking for help with figuring out on how clang determines visibility of shared object global symbols when compiled with '-fvisibility-hidden' and '-fvisibility-inlines-hidden'.
 
We own a pretty large code base and are trying to build it with clang. Unfortunately, when building using dynamic linking, we have some problems with visibility of global variables. For example, turned out clang handles -fvisibility-inlines-hidden flag a bit different to what gcc does. In our case, it leads to globals not being 'merged' by the linker, but every .so having its own copy of it.
 
So far we've been able to tackle these issues, but currently I am stuck with a relatively large part of of heavily templated code used as a 'singleton' global object. I am not able to reproduce that issue with a minimal example, I guess because of large number of classes that take part in instantiation of the singleton template (and if any of these classes is not exported, whole global object will not be exported). For some time I was looking through the code, searching for classes that may be missing 'visibility(default)' attribute, however it did not help.
 
What I'm looking for is some way to debug why a specific global object was not exported. Ideally, it would be a compiler/linker warning about not being able to export symbol explicitly marked with __attribute__(visibility(default)). However, any other debugging technique would be appreciated.
 
Kind regards,
Anton
 
 

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev