From owner-svn-src-all@FreeBSD.ORG Thu Feb 19 09:24:02 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC14765C; Thu, 19 Feb 2015 09:24:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ED5C854; Thu, 19 Feb 2015 09:24:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1J9NuwG075986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 11:23:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1J9NuwG075986 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1J9NtOb075985; Thu, 19 Feb 2015 11:23:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Feb 2015 11:23:55 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r278889 - head/lib/libc/include Message-ID: <20150219092355.GE34251@kib.kiev.ua> References: <201502170854.t1H8s4TL085174@svn.freebsd.org> <54E52019.8080009@FreeBSD.org> <20150219113226.K2984@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150219113226.K2984@besplex.bde.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 09:24:02 -0000 On Thu, Feb 19, 2015 at 11:58:48AM +1100, Bruce Evans wrote: > On Wed, 18 Feb 2015, Bryan Drewery wrote: > > > On 2/17/2015 2:54 AM, Konstantin Belousov wrote: > >> ... > >> Log: > >> Restore the extern qualifier on __cleanup. > >> ... > >> Modified: head/lib/libc/include/libc_private.h > >> ============================================================================== > >> --- head/lib/libc/include/libc_private.h Tue Feb 17 08:50:26 2015 (r278888) > >> +++ head/lib/libc/include/libc_private.h Tue Feb 17 08:54:03 2015 (r278889) > >> @@ -271,7 +271,7 @@ void _malloc_first_thread(void); > >> /* > >> * Function to clean up streams, called from abort() and exit(). > >> */ > >> -void (*__cleanup)(void) __hidden; > >> +extern void (*__cleanup)(void) __hidden; > >> > >> /* > >> * Get kern.osreldate to detect ABI revisions. Explicitly > >> > > > > Is this a NOP? > > No, since this is a data declaration. It would be a style bug on a > prototype. > > BTW, the reason for existence of __cleanup() has been broken by malloc() > and other bloatware. It is to avoid linking anything in stdio when > only exit() is used. But crtso now links to malloc() and malloc() > links to stdio and much more. When correctly (that is, statically) > linked, this bloats the size of a minimal C program from to 440K + 80K > symbols on amd64 and to 390K + 60K symbols on i386. In FreeBSD-4 and > in my version of FreeBSD-5, __cleanup still works and the minimal C > program has size 2K + 1.5K symbols. In FreeBSD-5, malloc() is > relatively unbloated, so crtso's linking to it costs only 9K + 9K > symbols instead of 400+K. The same program written in asm takes about > 10 bytes in all versions of FreeBSD-x86. When dynamically linked, > __cleanup() has little effect. I briefly looked at the possibility of removing __cleanup (*). Besides ensuring that all stdio FILEs are flushed at exit(3), it also ensures that stdio finalization is performed as the last action, after the whole chain of atexit(3) handlers was called. To repeat this behaviour, the flush handler must be registered very early, which would just mirror special behaviour of __cleanup, but at the startup. * Bruce, I do understand that your response is that we should fix malloc to not depend on stdio instead.