From owner-svn-src-head@FreeBSD.ORG Tue Jun 4 08:59:11 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77D1F7C1; Tue, 4 Jun 2013 08:59:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1173812A4; Tue, 4 Jun 2013 08:59:10 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r548wwIP018120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 18:59:03 +1000 Date: Tue, 4 Jun 2013 18:58:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jeremie Le Hen Subject: Re: svn commit: r250991 - in head: contrib/jemalloc/include/jemalloc include lib/libc/stdlib/jemalloc In-Reply-To: <20130531064239.GF70224@caravan.chchile.org> Message-ID: <20130604181934.R1018@besplex.bde.org> References: <201305251859.r4PIxChc053341@svn.freebsd.org> <20130531064239.GF70224@caravan.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=e/de0tV/ c=1 sm=1 a=rFD-CHOitREA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=sGq7gZRHcmUA:10 a=iBoK8JgcxXjK5WcVGSQA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Marcel Moolenaar , src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 08:59:11 -0000 On Fri, 31 May 2013, Jeremie Le Hen wrote: > On Sat, May 25, 2013 at 06:59:12PM +0000, Marcel Moolenaar wrote: >> ... >> Log: >> Make the malloc(3) family of functions weak and make their non-weak >> implementations visible for use by applications. The functions $F that >> are now weak symbols are: >> allocm, calloc, dallocm, free, malloc, malloc_usable_size, >> nallocm, posix_memalign, rallocm, realloc, sallocm >> .. > I don't understand what this brings. It apparently brings (exposes) lots of bugs :-). > If an application want to override > malloc() et al., it can just do it and the dynamic linker won't look up > the libc's version. This doesn't work for static linkage. Static linkage is non-broken, and doesn't allow replacing 1 symbol in an object file without replacing all of them, except possibly for weak symbols. Not replacing all of the symbols, by using the dynamic linkage bug or weak symbols, is very fragile. A program might replace malloc() and free() but not bother replacing calloc() because it doesn't use it. But a library might use it. The program shouldn't omit repacing calloc(). calloc() is a well-known public part of malloc() so it is easy to know that it needs to be replaced. But it is hard to know all the implementation details that need replacing. > Would you mind giving an example of what is now possible with this > change? I hope it will make it possible to replace malloc() so that small statically linked programs take 1K text again like they did in FreeBSD-3. In FreeBSD-4, malloc() now adds 360K to this in programs that don't want to use malloc() or stdio, because (poorly implemented) constructors reference it, and it references stdio (at least in the non-production version). Replacing it is difficult because of the complex dependencies of symbols. The first reference to it in a constructor was in atexit in FreeBSD-4, then malloc() only added 10K and was easy to replace. Bruce