Re: Porting libsanitizer to Solaris

[Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>]

On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth <ro@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