<div dir="ltr">> <span style="font-size:12.8px"> As a practical matter, I can't set $PLATFORM and/or $LIB in my rpath and have ld.so do the right thing in this context.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Can't Clang compile the sanitized executable with a special RPATH pointing to the correct libc++ folder?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Moreover, it is really a property of how you compiled, so I think using an alternate library name is natural.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Using an alternatively library names will likely cause problems if a non-sanitized libc++ is also present, since both libraries</span></div><div><span style="font-size:12.8px">provide the exact same symbols it's possible that symbols in the non-sanitized libc++ will replace the sanitized versions.</span></div><div><span style="font-size:12.8px"> </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 14, 2016 at 7:31 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Jonathan Roelofs via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> To: "Eric Fiselier" <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>>, "clang developer list" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, "Chandler Carruth"<br>
> <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>>, "Kostya Serebryany" <<a href="mailto:kcc@google.com">kcc@google.com</a>>, "Evgenii Stepanov" <<a href="mailto:eugenis@google.com">eugenis@google.com</a>><br>
</span><div><div class="h5">> Sent: Sunday, August 14, 2016 7:07:00 PM<br>
> Subject: Re: [cfe-dev] Making MSAN Easier to Use: Providing a Sanitized       Libc++<br>
><br>
><br>
><br>
> On 8/14/16 4:05 PM, Eric Fiselier via cfe-dev wrote:<br>
> > Sanitizers such as MSAN require the entire program to be<br>
> > instrumented,<br>
> > anything less leads to plenty of false positives. Unfortunately<br>
> > this can<br>
> > be difficult to achieve, especially for the C and C++ standard<br>
> > libraries. To work around this the sanitizers provide interceptors<br>
> > for<br>
> > common C functions, but the same solution doesn't work as well for<br>
> > the<br>
> > C++ STL. Instead users are forced to manually build and link a<br>
> > custom<br>
> > sanitized libc++. This is a huge PITA and I would like to improve<br>
> > the<br>
> > situation, not just for MSAN but all sanitizers. I'm working on a<br>
> > proposal to change this. The basis of my proposal is:<br>
> ><br>
> > Clang should install/provide multiple sanitized versions of Libc++<br>
> > and a<br>
> > mechanism to easily link them, as if they were a Compiler-RT<br>
> > runtime.<br>
> ><br>
> > The goal of this proposal is:<br>
> ><br>
> > (1) Greatly reduce the number of false positives caused by using an<br>
> > un-sanitized STL.<br>
> > (2) Allow sanitizers to catch user bugs that occur within the STL<br>
> > library, not just its headers.<br>
> ><br>
> > The basic steps I would like to take to achieve this are:<br>
> ><br>
> > (1) Teach the compiler-rt CMake how to build and install each<br>
> > sanitized<br>
> > libc++ version along side its other runtimes.<br>
> > (2) Add options to the Clang driver to support linking/using these<br>
> > libraries.<br>
> ><br>
> > I think this proposal is likely to be contentious, so I would like<br>
> > to<br>
> > focus on the details it. Once I have some feedback on these details<br>
> > I'll<br>
> > put together a formal proposal, including a plan for implementing<br>
> > it.<br>
> > The details I would like input on are:<br>
> ><br>
> > (A) What kind and how many sanitized versions of libc++ should we<br>
> > provide?<br>
> > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>---------------------<br>
> ><br>
> > I think the minimum set would be Address (which includes Leak),<br>
> > Memory<br>
> > (With origin tracking?), Thread, and Undefined.<br>
> > Once we get into combinations of sanitizers things get more<br>
> > complicated.<br>
> > What other sanitizer combinations should we provide?<br>
> ><br>
> > (B) How should we handle UBSAN?<br>
> > ------------------------------<wbr>---------------------<br>
> ><br>
> > UBSAN is really just a collection of sanitizers and providing<br>
> > sanitized<br>
> > versions of libc++ for every possible configuration is out of the<br>
> > question.<br>
> > Instead we should figure out what subset of UBSAN checks we want to<br>
> > enable in sanitized libc++ versions. I suspect we want to disable<br>
> > the<br>
> > following checks.<br>
> ><br>
> > * -fsanitize=vptr<br>
> > * -fsanitize=function<br>
> > * -fsanitize=float-divide-by-<wbr>zero<br>
> ><br>
> > Additionally UBSAN can be combined with every other sanitizer group<br>
> > (ie<br>
> > Address, Memory, Thread).<br>
> > Do we want to provide a combination of UBSAN on/off for every<br>
> > group, or<br>
> > can we simply provide an over-sanitized version with UBSAN on?<br>
> ><br>
> > (C) How should the Clang driver expose the sanitized libraries to<br>
> > the users?<br>
> > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>-------------------<br>
> ><br>
> > I would like to propose the driver option '-fsanitize-stdlib' and<br>
> > '-fsanitize-stdlib=<sanitizer><wbr>'.<br>
> > The first version deduces the best sanitized version to use, the<br>
> > second<br>
> > allows it to be explicitly specified.<br>
> ><br>
> > A couple of other options are:<br>
> ><br>
> > * -fsanitize=foo:  Implicitly turn on a sanitized STL. Clang<br>
> > deduces<br>
> > which version.<br>
> > * -stdlib=libc++-<sanitizer>: Explicitly turn on and choose a<br>
> > sanitized STL.<br>
> ><br>
> > (D) Should sanitized libc++ versions override libc++.so?<br>
> > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>-<br>
> ><br>
> > For example, what happens when a program links to both a sanitized<br>
> > and<br>
> > non-sanitized libc++ version?<br>
> > Does the sanitized version replace the non-sanitized version, or<br>
> > should<br>
> > both versions be loaded into the program?<br>
> ><br>
> > Essentially I'm asking if the sanitized versions of libc++ should<br>
> > have<br>
> > the "soname" libc++ so they can<br>
> > replace non-sanitized version, or if they should have a different<br>
> > "soname" so the linker treats them as a separate library.<br>
> ><br>
> > I haven't looked into the consequences of either approach in depth,<br>
> > but<br>
> > any input is appreciated.<br>
><br>
> In a sense, these are /just/ multilibs, so my inclination would be to<br>
> make all the soname's the same, and just stick them in appropriately<br>
> named subfolders relative to their normal location.<br>
<br>
</div></div>I'm not sure that's true; there's no property of the environment that determines which library path you need. As a practical matter, I can't set $PLATFORM and/or $LIB in my rpath and have ld.so do the right thing in this context. Moreover, it is really a property of how you compiled, so I think using an alternate library name is natural.<br>
<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><span class="im HOEnZb"><br>
><br>
><br>
> Jon<br>
><br>
> ><br>
> > Conclusion<br>
> > -----------------<br>
> ><br>
> > I hope my proposal and questions have made sense. Any and all input<br>
> > is<br>
> > appreciated.<br>
> > Please let me know if anything needs clarification.<br>
> ><br>
> > /Eric<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
> ><br>
><br>
> --<br>
> Jon Roelofs<br>
> <a href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a><br>
> CodeSourcery / Mentor Embedded<br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
<br>
--<br>
</span><div class="HOEnZb"><div class="h5">Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>