From owner-freebsd-current@FreeBSD.ORG Mon Sep 16 00:11:42 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 ABF35651 for ; Mon, 16 Sep 2013 00:11:42 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 758592E30 for ; Mon, 16 Sep 2013 00:11:42 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wo20so3188871obc.27 for ; Sun, 15 Sep 2013 17:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NiQTDItFwqIvvphsJCNY4Wcubjb6VMcQ9pnyXPXDoPE=; b=a5yHA/63U6bBQOv2RG91PcZDB7t2adcQ2cTYrQS+FexeA4a4QXRSt/3HXcEjWGtTem Cq+bDao73EZVgym4bSkP2u5/SbiBzBXyJBIIT1b4i0xDz1XtT5BfF2rxdMi9QzXst6N8 ETwc17cFeACPHpM7MypAlrym6PJt+EBY2NtCPGLF4Lp8PBC0bFbZmDQ60RY9uFFuyk/4 r+FjL0XnzaMd0J2FFQGHGcSdPB+LbsW8jmuQMTCHcv3OXPE6fA2phh42htNoGE7Z46aS fKDmAlPU1espmUs01HUayvLfY9iTPxrsJKZAlrBbSMZMSo1AtrWwm8N0KqrntRklqjmF 8j3g== MIME-Version: 1.0 X-Received: by 10.60.174.75 with SMTP id bq11mr31842oec.17.1379290301529; Sun, 15 Sep 2013 17:11:41 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.75.9 with HTTP; Sun, 15 Sep 2013 17:11:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 Sep 2013 17:11:41 -0700 X-Google-Sender-Auth: fjq5Y68xRTNADHzTP-tf42JWhiQ Message-ID: Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: Matthew Fleming To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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 00:11:42 -0000 On Sun, Sep 15, 2013 at 2:24 PM, Ed Schouten wrote: > Hi all, > > Today I did a tiny experiment and I am not entirely sure what to do. > Throw away the patch or eventually push it into the tree. > > GCC and Clang support the -ffunction-sections and -fdata-sections > flags. Essentially, these flags force the compiler to put every > function and variable in its own section. Though this will blow up the > size of the .o files a lot, it has a nice advantage. In combination > with ld's --gc-sections flag, it can garbage collect functions and > variables during the linking phase more accurately, thereby reducing > the size of the resulting binary. This will of course not work for > binaries where you want to use dlsym(), so this would only be safely > usable in cases where you want to do static linking. > > I've written a tiny patch for share/mk, crunchgen and /rescue, to set > these flags, only for .o files that are used for static linking (e.g. > for .a files) and when linking statically linked executables. > > http://80386.nl/pub/gc-sections.txt > > The results are interesting. On amd64: > > - 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. > > There is a downside, though. The total size of the system becomes 8 MB > larger, because the .a files in /usr/lib are a bit bigger than before. > Still, I think that this can be justified: > > - Systems short on disk-space are typically not used for software > development. As /usr/include and /usr/lib/*.a together already account > for ~30% of the disk space used, these files will likely be removed on > a disk-space constrained system anyway. > I can confirm that at least one vendor who is constrained on the size of the root partition does not install /usr/include or any *.a files. On shipping hardware. We do use the hardware for developer builds where we do need include files (though not .a files as we only use shared libraries). > - init and devd are so fundamental that they will likely be installed > on basically any embedded FreeBSD system. Reducing the size of these > binaries makes sense. > - It could also reduce the size of statically linked binaries outside > of the base system, depending on base libraries. > > What I also like about this, is that at least for the base system, it > will become less important to spread out functions in libraries over > separate source files, in an attempt to reduce the size of the > resulting binary. We may now leave functions that are related to each > other in the same source file, thus improving readability. > Would it be possible to enable this only for devd, init, and clang binaries? Or is it a matter of enabling it for library builds that are linked statically with the mentioned binaries? Could init/devd be made smaller by finding out which functions they do/don't use and separating those into separate .c files? Thanks, matthew