[llvm-dev] Policy for compiler-rt ABI stability and external dependencies?

[Dean Michael Berris via llvm-dev]

Hi Kostya, Evgenii, and David,

Recently I've been making some incremental changes to the XRay runtime implementation in compiler-rt to reduce the reliance on the C++ standard library components that might have external linkage dependencies. This involves not using containers from the STL and not using non-trivially destructible C++11 thread_local objects.

I was wondering whether the sanitisers follow an explicit policy of not depending on the C++ standard library or avoiding linkage/ABI issues that come up when building the sanitisers with C++ standard library dependencies. If it does, do we document these policies somewhere? If we don't document it somewhere, does it make sense for us to do so and maybe potentially enforce it at build time?

One of the policies I can think of is not to use *anything* from the C++ standard library even if they are templates anyway (e.g. std::unique_ptr<...>, std::shared_ptr<...>, std::tuple<...>, std::aligned_storage<...>, etc.). The downside to this would be myriad, where we'd need to implement analogues of these ourselves or resort to only things we can use from libc. I'm not sure how this could be automatically enforced, maybe potentially through a blacklist on `std::` types.

A slightly more permissive policy might be to allow using some of these types but not in any of the exposed interfaces and not require any runtime dependencies from the C++ standard library. This might be possible to enforce by checking the external/dymamic symbols in the runtime archives. I'm not sure though whether it's even safe to assume that the templates wouldn't introduce some weird ABI constraint even if the types don't cross the API boundaries.

I'm curious what the sanitisers currently do and what techniques/conventions we can follow on the XRay implementation that would be helpful to emulate as well.

In a similar vein, how do the sanitisers handle making ABI breaking changes? For the published types, is there a symbol naming policy and explicit deprecation/support horizon? How about API stability, do we intend to keep the API stable across N stable releases?

Your thoughts and feedback would be most appreciated.

Cheers

-- Dean