On 18/09/2013, at 6:42 PM, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > On Wed, Sep 18, 2013 at 05:36:40PM +1000, Jan Mikkelsen wrote: >> >> On 18/09/2013, at 4:22 PM, Konstantin Belousov <kostikbel_at_gmail.com> 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. >>>> >>>> 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. >>>> >>>> Would that sound okay? >>> >>> 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. >>> >>> 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. >> > 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. 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. >> >> 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. > > 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.Received on Wed Sep 18 2013 - 07:10:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC