Date: Mon, 16 Sep 2013 09:16:27 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: Ed Schouten <ed@80386.nl>, Adrian Chadd <adrian@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections Message-ID: <F80E219F-579A-4183-A64A-A09C5E80A4A2@FreeBSD.org> In-Reply-To: <B432059E-24BD-4799-9060-A3692DF78477@FreeBSD.org> References: <CAJOYFBBGY0GosPwG1B=1MKyapChEtX-O97r2zhXpGS8o7WO3gA@mail.gmail.com> <CAJ-Vmok6kTizGaoxoAC5Gx0gDgpCYCSk3s4a%2BdhQsuTRZdBDaw@mail.gmail.com> <B432059E-24BD-4799-9060-A3692DF78477@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Sep 2013, at 07:52, Dimitry Andric <dim@freebsd.org> wrote: > On Sep 16, 2013, at 03:08, Adrian Chadd <adrian@freebsd.org> wrote: >>> The results are interesting. On amd64: >>>=20 >>> - 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. >>>=20 >>=20 >> .. so, I'd like to know specific information as to why these three = are now >> smaller. So what's going on? >=20 >=20 > This is simply unreferenced code and data being eliminated. It is = quite > normal for libraries (libc, the LLVM libs, etc) to contain functions > that aren't called by the program you are linking. However, any .o = file > with multiple functions in it will be linked in as a whole, even if = just > one of the functions is called. >=20 > I really think functions and data should always be separately = "packaged" > in object files, but for some reason this has never been the default = for > GNU tools, and everybody has apparently copied the behavior. :-) Apple's ld, lld, and MCLinker all prefer to use a finer-grained model = (atoms or fragments) than segments, and so are intended to do this sort = of thing by default. This isn't an issue for dlsym(), as long as the = functions that you may wish to resolve using dlsym() are explicitly = marked (typically by including them in the version script) as not being = eligible for deletion - only functions and data reachable from the = public entry points should be retained. Of course, if you're building a = shared library and there is unreachable code or data, you probably have = a bug... Even in the shared library case, it's useful as it allows the linker to = rearrange functions and data to perform optimisations to minimise PLT = usage and improve cache and TLB usage by keeping functions that call = each other together and data with the functions that use it (profiling = can also help here, to prioritise hot functions). =20 David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F80E219F-579A-4183-A64A-A09C5E80A4A2>