Re: libsanitizer merge from upstream r196090

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

On Wed, Dec 4, 2013 at 8:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
>> > I believe this is a case where the GCC project gets more benefit from
>> > libsanitizer than libsanitizer gets from being part of the GCC
>> > project.  We should work with the libsanitizer developers to make this
>> > work, not just push everything back on them.
>> >
>>
>> I think libsanitizer should be disabled automatically if kernel or glibc are
>> too old.
>
> For very old I agree, I just strongly disagree with saying that anything
> older than a year and half is too old.
> So, as very old and unsupportable I'd probably consider e.g. Linux kernels
> without futex support, libsanitizer apparently uses those in various places
> and doesn't have a fallback.  The question is how to do that though, because
> libraries are now disabled through lib*/configure.tgt UNSUPPORTED=1, and
> that is sourced in by toplevel configure, so any configure checks would need
> to be in toplevel configure.  Or of course, we could in those cases
> configure the libsanitizer directory, but just decide not to build anything
> in there.
>
> Anyway, my preference right now would be if the ppc32 bits would be
> acceptable to Kostya (either by committing them upstream or just applying
> them as GCC local change for the time being),

Having GCC-local changes will make merges more painful in future, i.e.
I will not be able to make them.
I am ready to accept a ppc32 patch a) separately from other changes
and b) such that it applies upstream.
But long term we are not going to support platforms for which there
are no public build bots upstream.

> so that we don't break
> bootstrap on powerpc*-linux*, add those and commit the merge, then deal with
> the older kernel headers through include/linux subdirectory (I'll work on
> it), very old headers through configure, the CFI I hope Kostya would accept

Some kind of CFI support was just committed upstream, hopefully it works.
http://llvm.org/viewvc/llvm-project?rev=196480&view=rev

--kcc

> some macro, even if it is always enabled in the compiler-rt build and just
> GCC can disable .cfi_* addition if compiler doesn't use those, and then
> we can start fixing rest of portability issues.
>
>         Jakub