This is the mail archive of the
mailing list for the GCC project.
Re: Porting libsanitizer to Solaris
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: Alexander Potapenko <glider at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 4 Jul 2014 16:52:25 +0400
- Subject: Re: Porting libsanitizer to Solaris
- Authentication-results: sourceware.org; auth=none
- References: <20121114144356 dot GA29142 at bromo dot med dot uc dot edu> <CAG_fn=VQ11+1xYje2csJopXNYqzRk4qeVJutJPRButF8KLmvLA at mail dot gmail dot com> <yddr4nwi5nt dot fsf at manam dot CeBiTec dot Uni-Bielefeld dot DE> <CAG_fn=XuEVpEFQUL2kkvzcQk1u8Pq6jc2=9vPuQJUYqxDw9SAg at mail dot gmail dot com> <yddmwcpibvm dot fsf_-_ at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <CAGQ9bdz02gx903yXYrNmbhT+eC90HnU1dHQ46dL4tFanykcMbQ at mail dot gmail dot com> <yddiondi9jl dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE>
On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth <email@example.com> 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
>> 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
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.
> 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
>>> * 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 Orth, Center for Biotechnology, Bielefeld University