[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.11.1507022248340.27424@monopod.intra.ispras.ru>
Date: Thu, 2 Jul 2015 22:57:58 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
cc: Constantine <iamvfx@...il.com>
Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used
with musl
> i think the cause is that they intercept all allocation functions
> and if the act of interception calls into the intercepted function
> itself then they have a problem
This should never happen on musl since it links with -Bsymbolic-functions, and
even uses protected visibility now.
> 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)
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.
