This is an archive of the discontinued LLVM Phabricator instance.

[tsan] If the default target is not supported, don't build other targets either.
AbandonedPublic

Authored by dsanders on Jan 26 2016, 7:59 AM.

Details

Reviewers
hans
samsonov
Summary

This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.

When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.

There should be a better way to fix this but my attempts at a better solution
have run into difficulties (mostly related to preventing lit from testing the
default target). This at least solves the problem for now.

PR26278

Diff Detail

Event Timeline

dsanders updated this revision to Diff 45993.Jan 26 2016, 7:59 AM
dsanders retitled this revision from to [tsan] If the default target is not supported, don't build other targets either..
dsanders updated this object.
dsanders added reviewers: dvyukov, hans.
dsanders added a subscriber: llvm-commits.
dvyukov edited reviewers, added: samsonov; removed: dvyukov.Jan 26 2016, 8:05 AM
dvyukov added a subscriber: dvyukov.

Hi Dmitry,

I see you removed yourself as a reviewer. The reason I added you was that compiler-rt's CODE_OWNERS.txt lists you as the code owner for tsan and I therefore believe I'll need your approval to merge into the 3.8 release. Are you the right code owner for this patch?

samsonov edited edge metadata.Jan 26 2016, 9:57 AM

Hm, I'd really like to avoid this crutch, if possible. Do I understand that on MIPS32 platform we are able to build TSan to target MIPS64, but are not able to run tests, or build libcxx
with -fsanitize=thread? If that's the case, I would actually prefer to sink these checks to:
(a) test/tsan/CMakeLists.txt to either instantly return from CMakeLists.txt if default target arch is not in TSAN_SUPPORTED_ARCH, or use a loop to configure test suite for all arches in TSAN_SUPPORTED_ARCH like we do for ASan.
(b) don't call "add_custom_libcxx" from lib/tsan/CMakeLists.txt if default target arch is unsupported.

Hm, I'd really like to avoid this crutch, if possible. Do I understand that on MIPS32 platform we are able to build TSan to target MIPS64, but are not able to run tests, or build libcxx

with -fsanitize=thread?

The current state is that on MIPS32, the MIPS32 tsan is unsupported but tries to build a MIPS32 libcxx with -fsanitize=thread anyway (and fails stopping the build). If I hack around that then it tries to run the MIPS32 tsan tests (and fails them all). With the hack it successfully builds a MIPS64 tsan but doesn't attempt to build a MIPS64 libcxx with -fsanitize=thread and doesn't attempt to run the MIPS64 tsan tests.

If that's the case, I would actually prefer to sink these checks to:
(a) test/tsan/CMakeLists.txt to either instantly return from CMakeLists.txt if default target arch is not in TSAN_SUPPORTED_ARCH, or use a loop to configure test suite for all arches in TSAN_SUPPORTED_ARCH like we do for ASan.
(b) don't call "add_custom_libcxx" from lib/tsan/CMakeLists.txt if default target arch is unsupported.

My patch started off with the (b) approach. This solved the libcxx problem but it still ran the tsan tests for MIPS32 and failed them all. I later rewrote it using the loop approach in (a) but I couldn't get it to stop running the MIPS32 tests. At this point I decided that rc2 was looming and a hack was better than nothing so I posted this patch.

I kept the probably-good part of the (a) and I'll upload it shortly. The bit it's missing is my attempt to change the configure_lit_site_cfg() calls to skip MIPS32.

I've managed to get the (a) approach working. The patch is at http://reviews.llvm.org/D16685.

dsanders abandoned this revision.Jul 18 2019, 7:07 PM