From owner-freebsd-current@FreeBSD.ORG Wed Sep 18 00:26:48 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 695C2972; Wed, 18 Sep 2013 00:26:48 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 933922FDC; Wed, 18 Sep 2013 00:26:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VM5bS-000CrT-2C; Wed, 18 Sep 2013 00:26:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r8I0Qgje014359; Tue, 17 Sep 2013 18:26:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1//nH9EzIT1zHngo//NgepQ Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1379460140.1197.59.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 2013 18:26:42 -0600 Message-ID: <1379464002.1197.66.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Ed Schouten , FreeBSD Current , Matthew Fleming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 00:26:48 -0000 On Tue, 2013-09-17 at 16:31 -0700, Adrian Chadd wrote: > On 17 September 2013 16:22, Ian Lepore wrote: > > > On Tue, 2013-09-17 at 14:56 -0700, Adrian Chadd wrote: > > > ... I'd rather see if we can actually separate out things some more so > > > these builds can shrink. > > > > > > Eg, if there's malloc related functions that aren't used, maybe we should > > > break malloc down into a directory full of functions. > > > > > > > Why is that better than using this automated solution? > > > > Not everyone is going to run clang on their target development platform? :-) > > Personally I'd rather structure my work to behave better instead of doing > something that relies on a specific tool/suite to be able to optimise. The original mail began describing the feature with "GCC and Clang support the -ffunction-sections and -fdata-sections flags." I would much rather have the tools perform this mundane task, and keep the source code maintainable rather than artificially broken into a zillion tiny pieces. I'm interested in it for $work. We have lots and lots of .a libraries that get linked to make an app that also uses shared libs at runtime (libc et. al.). We often have large .o files with lots of C++ methods of a class in it, and only 2 or 3 of the methods may be actually used in a given app. I haven't tested it yet, but the way I'm picturing this working, we should get good savings because unused functions from all our .a libs won't get linked in, even though the overall app isn't static-linked. -- Ian