[cfe-dev] RFC: How should Clang/LLVM runtime libraries be installed and found during link steps?

[Chandler Carruth]

It has come up when reviewing Kostya's patch to add the necessary support
fort linking in the Address Sanitizer runtime library that we need a proper
scheme and plan for deploying runtime libraries along with Clang.

I've CC'ed llvmdev on this for compiler-rt developers' input.

The key issues I see when locating runtime libraries are the following:

- These libraries should be shipped with Clang, not installed separately on
the system.
- They are likely to be somewhat tied to specific versions of Clang/LLVM.
- To support cross-compiling, we should be able to install multiple copies
of these libraries in a single Clang installation, and use the appropriate
one when targeting a particular platform.
- The above cross-compiling concern extends to ABI compatibility -- many of
the ABIs are already fixed in this space.
- These are different from builtin header files which can use the
preprocessor to internally differentiate their contents based on the target
platform.

My proposed solution:

- Base the path on the shared "resource directory" concept which already
exists in Clang.
  - Builtin header files are at <ResourceDir>/include already.
- Append a "base" triple directory name.
- Append a "lib" directory name for runtime libraries
- Place the runtime libraries as "libcompiler_rt_<sublib>.a" for each
sub-library component "<sublib>".

Example for "x/bin/clang" installation:
  x/bin/../lib/clang/3.1/x86_64-linux-gnu/lib/libcompiler_rt_asan.a

What is a "base" triple? It is the simplest form we can reduce a triple to
while guaranteeing compatibility. The concept is best explained by an
example. All of the following triples reduce to the base triple of
"x86_64-linux-gnu":
  x86_64-linux-gnu
  x86_64-pc-linux-gnu
  x86_64-unknown-linux-gnu
  x86_64-redhat-linux
  x86_64-redhat-linux6E
  ...

A different ABI could be expressed much like ARM's is with the last
element: "*-gnueabi". This would *not* reduce to the triple ending in
'-gnu'. Due to the adhoc and poorly spec'ed nature of existing triples,
this will largely be a fixed mapping much like already exists in the Clang
driver, but consolidated into LLVM's core triple logic.


Open Questions:

How do we handle 'i686' vs 'i386'? Is it useful to have separate installed
libraries for i386 and i686 in order to get better performance for the
latter *and* maintain compatibility for the former? We could collapse to
either i386 or i686, and define either to mean whatever we want (for
example, Debian uses i386-linux-gnu for its "base" triple in multiarch, and
does *not* support i386 processors).

This scheme closely mirrors GCC's existing scheme with one exception: GCC
puts the triple first, and the version number second. I don't think this
matters greatly either way, but currently Clang puts its version number
first. I think this reflects the inherent design of Clang to be
cross-compiling by default, but it would be good to consider (even if we
reject) matching GCC's behavior here.

Should runtime libraries be installed as archives? .o files? .so files?
(gasp) bitcode? Some mixture of these? What mixture, and how do we decide?
I lean  toward .o files as bitcode where the linker supports it, normal .o
files where it supports those, and .a files only as a fallback. Not very
confident of these preferences though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111122/865fb8b1/attachment.html>