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), 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 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
