Date: Wed, 18 Sep 2013 11:42:24 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jan Mikkelsen <janm@transactionware.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: <20130918084224.GZ41229@kib.kiev.ua> In-Reply-To: <47786FBF-AA2A-4852-92AC-E612F03EA0AC@transactionware.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--iNbPU7EKMn+p5WBa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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> wrot= e: >=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 statica= lly > > 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 usua= lly done forever" doesn't contain a good argument, and compilers and linker= s on other platforms have been doing it like this for an awfully long time. >=20 Tools are not good. 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. 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. > 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 t= he flags means paying a bigger price when things are not perfect. And thing= s are very rarely perfect. >=20 > Having the structure of your source code driven by link-time consideratio= ns 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 w= ay 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. Yeah, make the things like nss, pam or iconv work or fully functional with the statically linked binaries first. --iNbPU7EKMn+p5WBa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSOWdvAAoJEJDCuSvBvK1BQY4P/AsXdKCO5SI0zksEaV2+Rbb9 Q1zqbBlfFa9nr2CQNz/nJEo5lh2MRheNUuSMQWW6bgwjUcL11mWKcRBk9lAwzY5q BYrVVp9fWx6JtbCAXh6MSJAywc+NSnb1KnMsBP4ptJyJ0Xrd03cJqu0zDrkPr3ZX 1Nm1SXfHcW2sK/kznBlpdb6vfBBbwo68JrQrbZIgW9134s2pGCn0eI7NChQBe7FN G9maFosbJFyc0+oezxhpMMZge4hfIw/lkuskcumw7+15HREPjv37ZZnYrdYNo+kd n2VhLvCKBV3FnJLbB9o8QCrRhmF6i7QxpyMAaTy2V93PyQHq564+Am4/pXubCCGc ++cqYmrCNI8qst5v8vVPg4qKsD6IzO1x24HCsHjFRF9FK2ORxWUZNA3oCEJp7GPn tJZ4uYWvzNLSwT4+ed58hkLyjr2zAIh16lJOZ718cel3zckWHHRdKfRdUDkqkxlE kMCpGXVxztfMRrLXcbVyg3v2uNnhr+8IWLzRCdsMmvnrMxszcHdq0OY42ruO5oIz lk7hRgib3z5Lw6ZodQGY6FuoRUSd7lom9C/j7c4cefVXLeqFGNQbRrBD/G3h3iaW 3Z0divAwkwOhfFOhM8wBs471tLxdRpjIq9kE2sXeN0sy3sGY2UPtGnbBmGBLrds5 AMPulPBcAG4Kfsup/tNw =uDbW -----END PGP SIGNATURE----- --iNbPU7EKMn+p5WBa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130918084224.GZ41229>