This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting libsanitizer to Solaris

Hi Konstantin,

> All contributions to libsanitizer should go via LLVM repository.
> See
> 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.  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
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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]