On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > Hi Konstantin, > >> All contributions to libsanitizer should go via LLVM repository. >> See https://code.google.com/p/address-sanitizer/wiki/HowToContribute >> The smaller the patches the faster they will come through. > > ok. I'll see how to split up the patches. Some parts are completely > trivial in that they treat Solaris exactly like Linux and FreeBSD. I > believe they could go in incrementally since they won't hurt other > ports, even if they don't enable the Solaris port yet until the last > step. > >> If you can set up a public build bot it will *immensely* simplify many >> things. >> (see more below) > > I fear this is going to be difficult: I don't have such a thing even for > GCC, and fighting with the buildbot software itself, another unfamiliar > build system (cmake has been my nemesis in the past) and a compiler that > doesn't even support Solaris (LLVM/Clang) is way more than I can spend > on this.
You don't have to fight with Clang on Solaris, and maybe not even with cmake. Recently we tried hard to make tests in compiler-rt become compiler-independent -- you can now run most of the asan tests in compiler-rt with any compiler that supports -fsanitize=address. https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerTestSuite So you'll need to checkout only the compiler-rt svn and test it against a compiler of your choice (e.g. gcc trunk) BTW, I really want to change our current scheme of merging sanitizer sources to gcc -- to use 'svn external' or some such instead of maintaining a copy. cmake support should be trivial and we will be able to help. > That's why I asked in the past why the libsanitizer > maintainers cannot act as liaisons between GCC (OS port maintainers > primarily) and LLVM/Compiler-RT, like Ian does for Go, to relieve the We do it to some extent. But we are not Ian and sanitizers are *much* more platform-dependent than Go. --kcc > burden of working in yet another `world'. I do regular (once a week > usually) GCC bootstraps on Solaris, so I will notice libsanitizer > breakage relatively quickly. > >>> A few random observations about the port: >>> >>> * From a porting point, I find it nightmarish that libsanitizer is >>> completely platform-based (SANITIZER_<PLATFORM> all over the place) >>> rather than feature-based (HAVE_<XYX>, irrespective of how the >>> features are detected). >> >> I don't enjoy the current situation. >> Any help here is welcome, but testing any such change might be complicated, >> especially for platforms which don't have public buildbots :( > > Agreed, but even in the GCC world, due diligence is considered enough: > test on a couple of common platforms and let the port maintainers deal > with the breakage if any. Not ideal but certainly better than delaying > cleanup work forever. > > Maybe I can come up with some suggestions when the Solaris port > finishes. > >>> * Even this is not consistent: many places use SANITIZER_<PLATFORM>, >>> others still __linux__/__FreeBSD__/... >> >> Again, patches are more than welcome to get rid of __linux__/__FreeBSD__/... > > Good. I may well do this as preparatory patches for the Solaris port > proper to make several parts cleaner (SANITIZER_SOLARIS is at least a > bit more readable than (defined(__sun__) && defined(__svr4__)) ;-) > > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University
