From owner-freebsd-current@FreeBSD.ORG Mon Sep 16 08:16:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 949499E; Mon, 16 Sep 2013 08:16:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 475BB2626; Mon, 16 Sep 2013 08:16:37 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r8G8GV6S057088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 08:16:32 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: David Chisnall In-Reply-To: Date: Mon, 16 Sep 2013 09:16:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dimitry Andric X-Mailer: Apple Mail (2.1508) Cc: Ed Schouten , Adrian Chadd , FreeBSD Current 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: Mon, 16 Sep 2013 08:16:38 -0000 On 16 Sep 2013, at 07:52, Dimitry Andric wrote: > On Sep 16, 2013, at 03:08, Adrian Chadd wrote: >>> The results are interesting. On amd64: >>>=20 >>> - devd suddenly becomes 500 KB in size, instead of a megabyte, >>> - init's size drops from 900 KB to 600 KB, >>> - clang becomes a megabyte smaller. >>>=20 >>=20 >> .. so, I'd like to know specific information as to why these three = are now >> smaller. So what's going on? >=20 >=20 > This is simply unreferenced code and data being eliminated. It is = quite > normal for libraries (libc, the LLVM libs, etc) to contain functions > that aren't called by the program you are linking. However, any .o = file > with multiple functions in it will be linked in as a whole, even if = just > one of the functions is called. >=20 > I really think functions and data should always be separately = "packaged" > in object files, but for some reason this has never been the default = for > GNU tools, and everybody has apparently copied the behavior. :-) Apple's ld, lld, and MCLinker all prefer to use a finer-grained model = (atoms or fragments) than segments, and so are intended to do this sort = of thing by default. This isn't an issue for dlsym(), as long as the = functions that you may wish to resolve using dlsym() are explicitly = marked (typically by including them in the version script) as not being = eligible for deletion - only functions and data reachable from the = public entry points should be retained. Of course, if you're building a = shared library and there is unreachable code or data, you probably have = a bug... Even in the shared library case, it's useful as it allows the linker to = rearrange functions and data to perform optimisations to minimise PLT = usage and improve cache and TLB usage by keeping functions that call = each other together and data with the functions that use it (profiling = can also help here, to prioritise hot functions). =20 David