From owner-freebsd-current@FreeBSD.ORG Wed Sep 18 07:43:26 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 B568F3AA for ; Wed, 18 Sep 2013 07:43:26 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id 0155624BE for ; Wed, 18 Sep 2013 07:43:25 +0000 (UTC) Received: (qmail 911 invoked by uid 907); 18 Sep 2013 07:36:42 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (202.68.173.218) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Wed, 18 Sep 2013 17:36:42 +1000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: Jan Mikkelsen In-Reply-To: <20130918062241.GW41229@kib.kiev.ua> Date: Wed, 18 Sep 2013 17:36:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <47786FBF-AA2A-4852-92AC-E612F03EA0AC@transactionware.com> References: <20130918062241.GW41229@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 18 Sep 2013 11:16:16 +0000 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 07:43:26 -0000 On 18/09/2013, at 4:22 PM, Konstantin Belousov = wrote: > On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote: >> [ ... ] >> Honestly, I think we can assume we'll never reach the point where all >> the components listed above will properly have all functions >> partitioned over separate compilation units. >>=20 >> I suspect that it would make a lot of sense to at least enable these >> build flags for our core libraries (libc, libc++, libpthread, >> libcompiler_rt, libcxxrt, etc). We could also enable it on >> INTERNALLIBs (libraries that are not installed into /usr/lib), as for >> these libraries, it would of course not come at any cost. >>=20 >> Would that sound okay? >=20 > I think this is a wrong direction. First, the split should be done at > the source level, as it was usually done forever. One of the offender > there was you, AFAIR. >=20 > Second, I would rather see init and devd, and in fact all other = statically > linked binaries from our base system, to become dynamically linked. = At > least I added a knob for building toolchain dynamic, but avoided the > fight of making this default. Why do things by hand when there are good tools? Note "... as it was = usually done forever" doesn't contain a good argument, and compilers and = linkers on other platforms have been doing it like this for an awfully = long time. Adding the flags has a benefit in the case where there are many = functions in a source file and minimal cost when everything is perfect. = Not having the flags means paying a bigger price when things are not = perfect. And things are very rarely perfect. Having the structure of your source code driven by link-time = considerations when there is a choice seems silly to me. Larger source = files gives the compiler more scope for optimisation, and you can = structure the code in a way useful to people working in the codebase. If you have a moral argument about how code should be structured, I = think that is separate discussion. Adding the flags has a benefit, = regardless of how the code is structured. I can see all upside, and I am = having trouble seeing a problem with adding them at all. On the static linking vs. dynamic linking argument: I am strongly on the = static linking side. But that is also a different discussion. Regards, Jan Mikkelsen