[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.11.1507030054550.27424@monopod.intra.ispras.ru>
Date: Fri, 3 Jul 2015 01:11:31 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used
with musl
> The problem is that we're still lacking any viable proposal for how
> this should work. Some constraints I think belong on a proposal for it
> to be viable include:
>
> - It should not place new constraints on the implementation in terms
> of requiring it to track information that would otherwise not be
> required and that may be costly, or to use particular internal
> representations of data/state, even when there's presently only one
> dominant representation in use. Any complex ot costly representation
> tracking should happen in the sanitizer layer, not libc.
>
> - It should be free of initialization order issues and thread-safety
> issues. This may mean that the sanitizer implementation has to use
> something like call_once all over the place.
>
> - It should work correctly with both static and dynamic linking, and
> should not depend on particulars of libc's dynamic linking -- in
> particular it should not depend on intra-libc allocator calls going
> through a PLT or via a symbolic GOT entry.
>
> Can you think of any others?
Perhaps this one?
- Natural composability, or nesting: a mechanism that allows sanitizers to
observe or interpose on some libc activity should naturally allow multiple
such interposers to co-exist.
For a write up on requirements from a sanitizer author's perspective, see
https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
Alexander
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.
