So, is there an agreement now? <div>In particular, is it fine to have the asan run-time for linux x86/x86_64 at </div><div>lib/clang/linux/TC.getArchName())/libclang_rt.asan.a ? </div><div><br></div><div>Thanks, </div><div>
<br></div><div>--kcc <br><br><div class="gmail_quote">On Mon, Nov 28, 2011 at 12:53 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey Chandler,<br>
<br>
We already have a certain precedent for how we do this on Darwin. The<br>
current library set is:<br>
--<br>
$ find lib/clang/3.1/lib<br>
lib/clang/3.1/lib<br>
lib/clang/3.1/lib/darwin<br>
lib/clang/3.1/lib/darwin/libclang_rt.10.4.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.cc_kext.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.eprintf.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.ios.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.osx.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.profile_ios.a<br>
lib/clang/3.1/lib/darwin/libclang_rt.profile_osx.a<br>
--<br>
It's entirely custom based on what the driver needs, and I find this<br>
to be very workable.<br>
<br>
In general, I view this as very much an "implementation detail" and<br>
see no need to over engineer here w.r.t. defining some formal schema<br>
up front. We can easily change it over time as we figure out what<br>
works. Unlike GCC we *never* want users to use these library names<br>
directly, and they are rev-locked to the compiler, which is why we can<br>
get away with treating the exact layout as an implementation detail.<br>
<br>
My preference would be that runtime libraries for broad platform<br>
classes (basically, darwin, linux, win32) fall under top level<br>
directories in the lib resource dir. Beyond that, any further<br>
subdivision should match whatever is easiest for the platform<br>
maintainers and driver implementation. I think we should just wait and<br>
review the code as it comes in.<br>
<br>
Note that I'm going to be checking in some code soonish to start<br>
setting these things up for Linux... it will be minimal and simple,<br>
and we can refine it over time as need be.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Daniel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 22, 2011 at 4:10 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> It has come up when reviewing Kostya's patch to add the necessary support<br>
> fort linking in the Address Sanitizer runtime library that we need a proper<br>
> scheme and plan for deploying runtime libraries along with Clang.<br>
> I've CC'ed llvmdev on this for compiler-rt developers' input.<br>
> The key issues I see when locating runtime libraries are the following:<br>
> - These libraries should be shipped with Clang, not installed separately on<br>
> the system.<br>
> - They are likely to be somewhat tied to specific versions of Clang/LLVM.<br>
> - To support cross-compiling, we should be able to install multiple copies<br>
> of these libraries in a single Clang installation, and use the appropriate<br>
> one when targeting a particular platform.<br>
> - The above cross-compiling concern extends to ABI compatibility -- many of<br>
> the ABIs are already fixed in this space.<br>
> - These are different from builtin header files which can use the<br>
> preprocessor to internally differentiate their contents based on the target<br>
> platform.<br>
> My proposed solution:<br>
> - Base the path on the shared "resource directory" concept which already<br>
> exists in Clang.<br>
>   - Builtin header files are at <ResourceDir>/include already.<br>
> - Append a "base" triple directory name.<br>
> - Append a "lib" directory name for runtime libraries<br>
> - Place the runtime libraries as "libcompiler_rt_<sublib>.a" for each<br>
> sub-library component "<sublib>".<br>
> Example for "x/bin/clang" installation:<br>
>   x/bin/../lib/clang/3.1/x86_64-linux-gnu/lib/libcompiler_rt_asan.a<br>
> What is a "base" triple? It is the simplest form we can reduce a triple to<br>
> while guaranteeing compatibility. The concept is best explained by an<br>
> example. All of the following triples reduce to the base triple of<br>
> "x86_64-linux-gnu":<br>
>   x86_64-linux-gnu<br>
>   x86_64-pc-linux-gnu<br>
>   x86_64-unknown-linux-gnu<br>
>   x86_64-redhat-linux<br>
>   x86_64-redhat-linux6E<br>
>   ...<br>
> A different ABI could be expressed much like ARM's is with the last element:<br>
> "*-gnueabi". This would *not* reduce to the triple ending in '-gnu'. Due to<br>
> the adhoc and poorly spec'ed nature of existing triples, this will largely<br>
> be a fixed mapping much like already exists in the Clang driver, but<br>
> consolidated into LLVM's core triple logic.<br>
><br>
> Open Questions:<br>
> How do we handle 'i686' vs 'i386'? Is it useful to have separate installed<br>
> libraries for i386 and i686 in order to get better performance for the<br>
> latter *and* maintain compatibility for the former? We could collapse to<br>
> either i386 or i686, and define either to mean whatever we want (for<br>
> example, Debian uses i386-linux-gnu for its "base" triple in multiarch, and<br>
> does *not* support i386 processors).<br>
> This scheme closely mirrors GCC's existing scheme with one exception: GCC<br>
> puts the triple first, and the version number second. I don't think this<br>
> matters greatly either way, but currently Clang puts its version number<br>
> first. I think this reflects the inherent design of Clang to be<br>
> cross-compiling by default, but it would be good to consider (even if we<br>
> reject) matching GCC's behavior here.<br>
> Should runtime libraries be installed as archives? .o files? .so files?<br>
> (gasp) bitcode? Some mixture of these? What mixture, and how do we decide? I<br>
> lean  toward .o files as bitcode where the linker supports it, normal .o<br>
> files where it supports those, and .a files only as a fallback. Not very<br>
> confident of these preferences though.<br>
</div></div></blockquote></div><br></div>