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

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/llvm-dev/attachments/20111122/865fb8b1/attachment.html>

Hey Chandler,

We already have a certain precedent for how we do this on Darwin. The
current library set is:
--
$ find lib/clang/3.1/lib
lib/clang/3.1/lib
lib/clang/3.1/lib/darwin
lib/clang/3.1/lib/darwin/libclang_rt.10.4.a
lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a
lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a
lib/clang/3.1/lib/darwin/libclang_rt.ios.a
lib/clang/3.1/lib/darwin/libclang_rt.osx.a
lib/clang/3.1/lib/darwin/libclang_rt.profile_ios.a
lib/clang/3.1/lib/darwin/libclang_rt.profile_osx.a
--
It's entirely custom based on what the driver needs, and I find this
to be very workable.

In general, I view this as very much an "implementation detail" and
see no need to over engineer here w.r.t. defining some formal schema
up front. We can easily change it over time as we figure out what
works. Unlike GCC we *never* want users to use these library names
directly, and they are rev-locked to the compiler, which is why we can
get away with treating the exact layout as an implementation detail.

My preference would be that runtime libraries for broad platform
classes (basically, darwin, linux, win32) fall under top level
directories in the lib resource dir. Beyond that, any further
subdivision should match whatever is easiest for the platform
maintainers and driver implementation. I think we should just wait and
review the code as it comes in.

Note that I'm going to be checking in some code soonish to start
setting these things up for Linux... it will be minimal and simple,
and we can refine it over time as need be.

 - Daniel

On Tue, Nov 22, 2011 at 4:10 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 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.

So, is there an agreement now?
In particular, is it fine to have the asan run-time for linux x86/x86_64 at
lib/clang/linux/TC.getArchName())/libclang_rt.asan.a ?

Thanks,

--kcc

On Mon, Nov 28, 2011 at 12:53 PM, Daniel Dunbar <daniel at zuster.org>
wrote:
> Hey Chandler,
>
> We already have a certain precedent for how we do this on Darwin. The
> current library set is:
> --
> $ find lib/clang/3.1/lib
> lib/clang/3.1/lib
> lib/clang/3.1/lib/darwin
> lib/clang/3.1/lib/darwin/libclang_rt.10.4.a
> lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a
> lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a
> lib/clang/3.1/lib/darwin/libclang_rt.ios.a
> lib/clang/3.1/lib/darwin/libclang_rt.osx.a
> lib/clang/3.1/lib/darwin/libclang_rt.profile_ios.a
> lib/clang/3.1/lib/darwin/libclang_rt.profile_osx.a
> --
> It's entirely custom based on what the driver needs, and I find this
> to be very workable.
>
> In general, I view this as very much an "implementation detail"
and
> see no need to over engineer here w.r.t. defining some formal schema
> up front. We can easily change it over time as we figure out what
> works. Unlike GCC we *never* want users to use these library names
> directly, and they are rev-locked to the compiler, which is why we can
> get away with treating the exact layout as an implementation detail.
>
> My preference would be that runtime libraries for broad platform
> classes (basically, darwin, linux, win32) fall under top level
> directories in the lib resource dir. Beyond that, any further
> subdivision should match whatever is easiest for the platform
> maintainers and driver implementation. I think we should just wait and
> review the code as it comes in.
>
> Note that I'm going to be checking in some code soonish to start
> setting these things up for Linux... it will be minimal and simple,
> and we can refine it over time as need be.
>
>  - Daniel
>
> On Tue, Nov 22, 2011 at 4:10 PM, Chandler Carruth <chandlerc at
google.com>
> wrote:
> > 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/llvm-dev/attachments/20111129/453939e4/attachment.html>