From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8096 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl Date: Thu, 2 Jul 2015 22:57:58 +0300 (MSK) Message-ID: References: <20150702190037.GJ1173@brightrain.aerifal.cx> <20150702192916.GI32532@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: ger.gmane.org 1435867092 32127 80.91.229.3 (2 Jul 2015 19:58:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2015 19:58:12 +0000 (UTC) Cc: Constantine To: musl@lists.openwall.com Original-X-From: musl-return-8109-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 02 21:58:12 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZAkcd-0005YU-Rz for gllmg-musl@m.gmane.org; Thu, 02 Jul 2015 21:58:11 +0200 Original-Received: (qmail 3390 invoked by uid 550); 2 Jul 2015 19:58:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3369 invoked from network); 2 Jul 2015 19:58:09 -0000 In-Reply-To: <20150702192916.GI32532@port70.net> User-Agent: Alpine 2.11 (LNX 23 2013-08-11) Xref: news.gmane.org gmane.linux.lib.musl.general:8096 Archived-At: > 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