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.