From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11638 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC PATCH] Allow annotating calloc for Valgrind Date: Sun, 2 Jul 2017 12:31:11 -0400 Message-ID: <20170702163111.GL1627@brightrain.aerifal.cx> References: <20170629225614.19061-1-amonakov@ispras.ru> <20170629232032.GH1627@brightrain.aerifal.cx> <20170629235624.GI1627@brightrain.aerifal.cx> <20170702143539.GK1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1499013091 3099 195.159.176.226 (2 Jul 2017 16:31:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Jul 2017 16:31:31 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11651-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 02 18:31:25 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dRhmJ-0000IK-To for gllmg-musl@m.gmane.org; Sun, 02 Jul 2017 18:31:19 +0200 Original-Received: (qmail 26233 invoked by uid 550); 2 Jul 2017 16:31:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26212 invoked from network); 2 Jul 2017 16:31:22 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11638 Archived-At: On Sun, Jul 02, 2017 at 07:16:15PM +0300, Alexander Monakov wrote: > On Sun, 2 Jul 2017, Rich Felker wrote: > > I'm not sure it makes sense to do -- is there a good reason dynamic > > linking can't be used when debugging memory errors? Surely some apps > > (especially proprietary ones) might be shipped as static binaries, but > > these will likely lack debugging symbols anyway. > > Perhaps the project is hard to rebuild with shared libc.so, for reasons > like using linker functionality (e.g. --wrap, linker scripts) that does > not have direct equivalents outside of fully-static linking. > > But in any case, even if there are doubts as to *why* people do it, we > know for certain that people hit this issue - there were two independent > reports on the mailing list this month. It would be nice to come up with > some kind of "canonical answer" for those situations - is it going to be > "just don't use static linking"? I think "debugging tool X has inherent limitations with static linking, so you should dynamic-link to use it" is a fairly reasonable position to take. Switching to dynamic-linking everything may be complex or difficult for some larger projects, but just dynamically linking libc.so and static linking everything else should not be hard. > > There are also fundamental limits to the correctness of any approach > > that uses static linking, since too much information has already been > > lost. It's calling the _name_ malloc, realloc, or free (not the code > > at the location; think aliases etc.) that must have the allocation > > semantics. Even if nothing weird is happening with aliases at the libc > > implementation level, the compiler could do major transformations with > > IPA (especially with LTO) that end up resulting in code being shared > > in unexpected ways. > > Are you sure the same theory doesn't apply with shared libc.so? When you > call malloc internally in libc.so (e.g. printf->...->realloc), you're not > calling it via a dynamic relocation. Well printf doesn't call realloc, but some things will, and yes I think you're right. This problem might go away if we made an effort to actually support malloc interposition (with a well-defined model for what you can and can't do rather than just being sloppy about it) since libc-internal callers would have to go through the same interfaces, but there's been some question whether, if we did this, purely libc-internal (i.e. not "as if by malloc") allocations would be subject to interposition or would always use an internal malloc. Maybe it doesn't matter one way or the other if we assume there are not bugs in the purely libc-internal use of the allocator. Rich