Date: Wed, 18 Sep 2013 19:11:11 +1000 From: Jan Mikkelsen <janm-freebsd-current@transactionware.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ed Schouten <ed@80386.nl>, FreeBSD Current <freebsd-current@freebsd.org>, Matthew Fleming <mdf@freebsd.org> Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections Message-ID: <98E31AD4-29B1-410D-B2BB-5BBBBA2F2767@transactionware.com> In-Reply-To: <20130918084224.GZ41229@kib.kiev.ua> References: <CAJOYFBBGY0GosPwG1B=1MKyapChEtX-O97r2zhXpGS8o7WO3gA@mail.gmail.com> <CAMBSHm_Qk13P=j1VOzuibYaeHFVF%2BCuXbTYL=q8ToDP6wL5X5w@mail.gmail.com> <CAJOYFBBUT5v1E6L0JkdrAXFmJmR0W2tmyNrC71k8mahLiF5vWg@mail.gmail.com> <20130918062241.GW41229@kib.kiev.ua> <47786FBF-AA2A-4852-92AC-E612F03EA0AC@transactionware.com> <20130918084224.GZ41229@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18/09/2013, at 6:42 PM, Konstantin Belousov <kostikbel@gmail.com> = wrote: > On Wed, Sep 18, 2013 at 05:36:40PM +1000, Jan Mikkelsen wrote: >>=20 >> On 18/09/2013, at 4:22 PM, Konstantin Belousov <kostikbel@gmail.com> = wrote: >>=20 >>> 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. >>=20 >> 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. >>=20 > Tools are not good. >=20 > Using of this feature locks us to the toolchain. And, the = implementation > of at least gc in the linker is known to be buggy even in recent = binutils. Which candidate toolchain doesn't have this feature? Also: Using this = feature does not preclude code being structure to also support those = tools. Buggy as in "generates broken binaries" or as in "doesn't collect all = the garbage"? If it is "generates broken binaries" then your argument is = that it doesn't work: Please provide an example. If your argument is = that it doesn't collect all the garbage, I don't see that it matters. = That will improve, but is not a strong argument against the approach. > Also, even perfect linker cannot always guess the correct value of = garbage, > so we have to hack in other direction. With the current set-up, it is > easy to guarantee that some symbol is always present if other symbol > is linked in. Why do you care? The linker will not get rid of externally visible = symbols. >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> On the static linking vs. dynamic linking argument: I am strongly on = the static linking side. But that is also a different discussion. >=20 > Yeah, make the things like nss, pam or iconv work or fully functional > with the statically linked binaries first. Sure, dynamic libraries have a place. That's why its a separate = discussion. Regards, Jan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98E31AD4-29B1-410D-B2BB-5BBBBA2F2767>