[PATCH] D102090: [CMake][ELF] Link libLLVM.so and libclang-cpp.so with -Bsymbolic-functions

Mon Dec 6 10:58:15 PST 2021

rnk added a comment.

In D102090#3172693 <https://reviews.llvm.org/D102090#3172693>, @ebrevnov wrote:

> I don't see what's wrong here (maybe you have specific example). IMHO, quite opposite, LLVM will consistently use it's own instance while user's binary it's own as if  there were two globals with different names in the first place. I have exactly that real life case where LLVM's function (coming from libLLVM*.so since functions are not interposed) refers to a global from the user's binary with the same name by completely different semantics.

In my experience, in C++, the problem you describe is uncommon because globals are typically namespaced, so there are rarely clashes between user code and LLVM. The problem you describe arises more often when two different versions of LLVM are linked into different DSOs. Yes, one could probably attempt to use -Bsymbolic to defend against these symbol conflicts, but there may still be conflicts over other process global resources such as signal handlers.

>> If you arrange the same situation with functions, they are usually functionally equivalent even if there are minor code differences.
>
> I don't think it is safe to assume that. Maybe in most cases, but not always.

If you have two function definitions with the same name that semantically differ, that's a C++ ODR violation, so it's usually a pretty safe assumption.

>> Generally, users are not trying to preempt LLVM's own function definitions. The typical use cases are to override C library functionality such as malloc. The performance benefit of -Bsymbolic-functions is worth making LLVM's own functions non-interposable.
>
> I don't think this is really relevant to the subject since performance is outside of the scope of my question. The question is if -Bsymbolic can protect us from unintentional preemption by user defined globals.

I think you could certainly try, but it risks creating the first issue that I described, duplicate copies of vague linkage globals. A concrete example of one of these issues is the `llvm::Any` template:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ADT/Any.h#L28

If the user instantiates `llvm::Any` outside of the main LLVM DSO, there will be a second copy of this typeid global, and Bsymbolic will stop the loader from coalescing them. Depending on how you use LLVM's C++ APIs, your risk of these issues may vary.

In any case, -Bsymbolic is not a good default for the project because of issues like this.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102090