[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
