On macOS/arm, signature verification has kill semantics by default.
Signature verification is cached with a file's inode (actually, vnode),
and if a new executable is copied over an existing file (which reuses
the inode), the cache isn't invalidated. So when the new executable
is executed, the kernel still has the old content's signature cached
and the kills the executable because the old signatue doesn't match
the new contents (https://openradar.appspot.com/FB8914243).
As workaround, rm the desitnation files first, to ensure they have
a fresh vnode (and hence no stale cached signature) after the copy.
Part of PR46647. See also e0e334a9c1 for a similar change.
When a LLVM binary such as llvm-*-fuzzer is built with libc++, it has dependency on libc++. The path to find shared libraries specified in llvm-*-fuzzer is relative. As a result, these binaries cannot be copied to an arbitrary directory and launched from there. Changes in this patch add a LIT feature to indicate that libc++ is used to build and, based on the feature exclude test cases that test by copying llvm-*-fuzzer binaries to a directory.
Reviewers: hubert.reinterpretcast, dberris, amyk, jasonliu, EricWF
Reviewed By: hubert.reinterpretcast, amyk
Subscribers: javed.absar, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61265
llvm-svn: 360672
This broke some Windows buildbots; see llvm-commits thread.
> These were just copies of the relevant fuzzer binary with (presumably)
> meaningful suffixes, but accounted for more than 10% of my build
> directory (> 8GB). Hard drive space is cheap, but not that cheap.
(Also reverts follow-up r326710 which didn't help.)
llvm-svn: 327266
These were just copies of the relevant fuzzer binary with (presumably)
meaningful suffixes, but accounted for more than 10% of my build
directory (> 8GB). Hard drive space is cheap, but not that cheap.
llvm-svn: 326710
Nico Weber