[llvm-dev] Meet at MTV to discuss TSAN/android/aarch64?
enh via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 24 17:39:13 PDT 2015
On Thu, Sep 24, 2015 at 11:18 AM, Jason Kim <jasonk at codeaurora.org> wrote:
> Hi everyone.
> Thanks to everyone for taking the time to meet yesterday. I think it was
> very productive!
> I am writing to keep a "minutes" of the meet, as I remember them.
> Action Items:
> Jasonk: split up bionic patch to explicitly replace CPP macros with actual
> calls, one file at a time.
> Google/Android: pthread_barrier interface in bionic
> Enh: 1 paragraph to explain "namespacing" in bionic?? (in case we need to
> reconsider macro replacement again?)
grep for "namespace.h" and "un-namespace.h". interestingly, freebsd
and netbsd have this but openbsd doesn't.
> Some technical notes/explanations that possibly weren't made clear at the
> The current compller-rt patch (on phabricator) is already a pretty minimal
> set. The only real bit of actual functionality (other than the
> infrastructure bits to enable TSAN on android/aarch64) is the TLS
> i.e. the major pieces for my patch to compiler-rt are:
> infrastructure (new definitions, cmake changes etc..)
> TLS workaround
> pthread_barrier-like interface for tests
> disabling of some tests on android-aarch64
> My current hypothesis is that the 120 tests (out of 200 or so) that are
> failing are due the behavioral mismatch of my "quick hack" to enable
> barrier-like behavior on android. Assuming that Google's implementation of
> the barrier interface on android/aarch64 is a better fit with linux-x86_64,
> this will hopefully result in more tests passing.
> Very important info regarding why __bionic_XXX() replacement for calls to
> XXX() will most likely need to be "global" (within bionic) in most cases:
> deadlocks, crashes in TSAN were all due to unexpected interceptions WHILE a
> call was already being intercepted by TSAN.
> The most obvious TSAN-only workaround is to ignore interceptions when this
> is taking place. This works for two threads, but does not scale to more
> threads without the danger of TSAN missing events.
> Any unexpected nested call chains in bionic that TSAN currently intercepts
> will either need custom coding in TSAN to explicitly handle (for all
> possible cases in which such call chains can occur), OR replace those calls
> in bionic with non-interceptible ones. The former will obviously add much
> more complexity to TSAN (to wit, additional testing failure vulnerability),
> while the latter will mean more (mechanical) changes to BIONIC. Currently,
> my thinking is that the latter, (being mechanical in nature) is preferable.
> To ENH: The same holds for calls to tcgetattr() --> ioctl(), and isatty() ->
> tcgetattr() --> ioctl() call chains. TSAN intercepts tcgetattr() and
> ioctl(), and is not expecting recursive interceptions during them.
what does this mean?
> Its not
> at all clear how to handle this within TSAN, especially among multiple
> threads. Even if a logic can be worked out, it's fundamentally much clearer
> to simply disallow such interceptions to occur.
> Things that might require future discussion:
> need a build-bot/test bot on labs.llvm.org for android-bionic-aarch64-tsan
> tests to prevent insanity inducing regressions :-)
> Thanks for reading!
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
More information about the llvm-dev