<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 1:54 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 30 January 2014 21:50, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don't see any compelling reason to split the sanitizers out today.</div></div></div></div></blockquote><div><br></div></div><div>Clear, next.</div>
</blockquote></div><br>Just as a side note, I had some thoughts about the organization of this stuff a while back that I wanted to replay here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fundamentally, I feel like we're in particular getting a few things conflated. Maybe separating them out helps:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- There is the repository "compiler-rt" that holds all of the runtime libraries that (if desired) need to be shipped along side the compiler. They're separated so that they can be omitted when they aren't needed, and potentially to isolate an unusual desired property: we would really like to (eventually) build them with the just-built compiler rather than the host compiler (where possible, clearly this requires the target compiler to be executable on the host).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- There is the core runtime library. Historically this was called 'compiler-rt' informally, but perhaps better called 'libclang_rt', which provides the core necessary runtime library facilities to compile C or C++ applications. It's analogous to libgcc but without some of the unwinding code (as I understand it, there may be details I'm wrong about here or glossing over, but it's not relevant to the organization of things).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- There are several optional runtime libraries to support specific compiler / toolchain features. These include the sanitizers and profiling libraries.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I think all of the libraries here make sense in the same repository because of the shared concerns of building runtime libraries. For example, it would be useful to compile them with the just-built-clang when target is executable on the host, and it would be useful to automatically cross compile versions of them for as many targets as are possible on the given host and supported by the host compiler (if used) and the just-built-clang.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However, the organization of the tree is ... very hard to understand. originally, there was only the one 'libclang_rt' library that had its generic C99 implementation in 'lib', and architecture-specific assembly routines when desirable in architecture subdirectories of lib. When we added new libraries, we put them in subdirectories of lib, making the whole thing kind of a mess. My suggestion to fix this was to create a "core" subdirectory of lib to contain the code used for 'libclang_rt'. "core" is a terrible name, but i've no better. suggestions welcome there. Then we would have a more sensible organization of the 'lib' tree.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I also think it might be useful to have a single large test tree (much like with llvm or clang) that has subdirectories for the various tests rather than test directories under lib/asan/ and friends, but maybe the sanitizer folks have objections to that. consistency seems a compelling reason here, but there might be other compelling concerns.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Now, the build system has always been problematic because the build system for this tree is *hard* and no one who has worked on it has really had the time to do an extremely thorough job and finish all aspects. It's a huge project. Right now, the makefile system does a good job of using the just-built-clang and can do a limited amount of cross-building runtimes for other targets. But the makefile system of compiler-rt is also terribly, terribly complex, doesn't follow the conventions of LLVM's makefiles, and is generally painful to maintain and update, so folks have been reluctant to flesh out its support for new libraries and other new things.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The CMake system is much cleaner in some respects (a bit less opaque to the folks trying to maintain it), but CMake makes it much harder to use the just-built-clang, especially for the C++ runtime code. The consequence is that we've never finished either the cross-building or just-built-clang-hosting features that are desirable. Any work toward these would be really awesome to see, but is a huge pile of work. Finally, when I was originally doing the CMake build for this I didn't understand what really needed to be done to build and use the core 'libclang_rt' library, and so I don't think I got it right. Some folks have sent patches to improve it, but I suspect it still really needs more work to be a solid system to use instead of libgcc. So I'm really excited about your emails. =] Having a more self-contained stack would be a significant improvement.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the obvious incremental steps are to disable building any parts of compiler-rt that don't build cleanly. There should never be a requirement for you to port an optional runtime library unless you need it. =] I think having good ports is important, but that should never block progress getting other thinsg ported and working well.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If it helps to reorganize things, I'm happy to even help there as much as I can. I agree that the organization isn't great, but I *really* didn't want to fight the makefile build system to do the reorganization myself, so its something that has lingered too long.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry for the long ramble, but hopefully this gives you some of tho context.</div></div>