From owner-freebsd-current@FreeBSD.ORG Sun Sep 15 21:24:09 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 E17D19CA for ; Sun, 15 Sep 2013 21:24:09 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A46C9268B for ; Sun, 15 Sep 2013 21:24:09 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jz11so2355654veb.39 for ; Sun, 15 Sep 2013 14:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=WX8faPCznXcL51KNYK/3/x/vAO0eyraJ0MZSeAvZQDc=; b=LRxgm1H71/Ogny45qcd+jC2/L1h+y5unslppzfltzAyOVIeuQb4vBshbBH2QoQEdt4 JgPP/Sq5tsZjGeAbIz81XCfTBLXOcYj1InsmDWqEw6U5Zdn5yVlRhGoZLH2+qbBB9MeX 3T/QWBm3p3Uq/0eaUZfdbe/tqLeYea2s1LIkEYmR5WOmvjZXvV77kgVNkh4VYSTGYpL9 ULgW5chg43QMwvDE6CRkHEYNfxpe68BknrOFncUdWebhM+MU8PI9LXFT3TS03jeEBRMA Jp9HeSdj0XvaPz5trsEDOgK/G9IiaZTOuzORpelPdDsA/GtDx9gy8urDDII/DUC+mkcS 4sig== MIME-Version: 1.0 X-Received: by 10.59.11.69 with SMTP id eg5mr5257348ved.17.1379280248491; Sun, 15 Sep 2013 14:24:08 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.115.206 with HTTP; Sun, 15 Sep 2013 14:24:08 -0700 (PDT) Date: Sun, 15 Sep 2013 23:24:08 +0200 X-Google-Sender-Auth: pX8Aqljwpc1Rck9Qb1bklP3DXsc Message-ID: Subject: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: Ed Schouten To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 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: Sun, 15 Sep 2013 21:24:09 -0000 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. - 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. Thoughts? -- Ed Schouten