[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Jul 2015 16:20:27 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used
with musl
On Thu, Jul 02, 2015 at 10:57:58PM +0300, Alexander Monakov wrote:
> > for glibc calloc they have some ugly workaround, maybe similar hack
> > is needed for free in musl, but none of this is future proof so
> > they will just keep piling hacks..
>
> Re: hacks, I think it doesn't have to be like that. There should be a
> reasonable mechanism to wrap library functions in the context of dynamic
> linking; static linking is slightly ahead in that game if you count ld
> --wrap=symbol functionality.
>
> For dynamic linking it should be doable with a new type of ELF tag and a bit
> of support from the dynamic linker. Would you be interested?
>
> (at the moment I don't have an answer why lsan started failing like that; and
> even if, hypothetically, there would be a good library wrapping mechanism,
> sanitizers would likely need other support from libc, like dynamic tls layout
> discovery for memory sanitizer; I hope it can be resolved to everyone's
> satisfaction eventually, improving sanitizers usability, rather than ignoring
> it and perpetually calling sanitizers a pile of hacks)
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?
Rich
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.
