|
Message-ID: <20210527030927.xsst3qmo3ucaprjz@gmail.com> Date: Wed, 26 May 2021 20:09:27 -0700 From: Fangrui Song <i@...kray.me> To: Florian Weimer <fweimer@...hat.com> Cc: Kostya Serebryany <kcc@...gle.com>, Evgenii Stepanov <eugenis@...gle.com>, enh <enh@...gle.com>, libc-coord@...ts.openwall.com Subject: Re: Thread properties API On 2021-05-23, Fangrui Song wrote: >Thanks for proposing this. > >On 2021-05-21, Florian Weimer wrote: >>In glibc, we have a historic gap when it comes to access to per-thread >>data that may contain application data. Such functionality is required >>to support memory leak detectors and conservative garbage collectors >>that need to discover pointer values in TLS data. The sanitizers >>currently hard-code glibc implementation details (that are not really >>unchanging in practice), and we want to switch to a defined interface >>eventually. >[...] > >Currently msan and tsan intercept __tls_get_addr so that newly allocated TLS >can be tracked and immediately acted upon. See my attached notes for >details. >(Note: aarch64 uses TLSDESC by default and there is no interposable symbol.) > >Is there an observer API for the new allocated TLS area? >(msan's hook is async-signal-safe (even though lazy TLS allocation >isn't). It does very simple unpoison operation.) > https://github.com/google/sanitizers/issues/1409 "Detect dynamic TLS allocations for glibc>=2.19" provides more context on the dynamic TLS detection needs. It is motivated by a recent msan false positive due to TLS inconvenience ;-) In the near term (a few years?) sanitizers may need to work around the issue, but hope the API can make the future world more robust:) > > >[I am attaching my notes about sanitizer runtime's usage of TLS >boundaries. Hope that can be useful.] > >[...]
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.