Date: Mon, 14 Sep 1998 17:40:44 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: Terry Lambert <tlambert@primenet.com> Cc: graphix@iastate.edu (Kent Vander Velden), tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Unused functions Message-ID: <199809142240.RAA09355@detlev.UUCP> In-Reply-To: <199809142021.NAA26933@usr05.primenet.com> References: <199809142021.NAA26933@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Just so I completely understand, if I truely use only one function in from >> a .o file and no other function is using anything in this .o file, the >> entire .o file is still pulled into the executable? So, there are could be >> a lot of unused, unreachable code in an executable. > Yes, if it's statically linked, and you poorly organize your code. > This is why software engineers make more money than mere programmers. This is also why most libraries tend to define one exported function per object file, or sometimes exported functions that are always used together (foodb_open, foodb_close). >> Nothing can be done to remove the bloat after the executable has >> been linked? > Not quite. But nothing *is* done... What can be done in the compiler and linker alone? If an object file contains both foo() and bar(), and foo calls bar, the linker doesn't know that. Neither does it know about static baz(), which only quux() calls. The user program doesn't call quux, and therefore doesn't call baz, but the linker doesn't know that. I don't see any way to resolve the issue without instrumenting the object file (perhaps by extending stabs?). If that were to be done, then something similar to lorder would do the trick. >> I had always assumed that unused functions and data were tosed out. > No. Only for compilers and linkers that optimize for image size > and execution speed, instead of for compiler benchmarks. > Q: Do you buy a compiler that is very fast, or do you buy the > compiler that makes very fast code? I prefer a compiler that has the choice. This isn't hard, particularly since several optimizations-- including the one under discussion-- are handled by passes over intermediate representations of the code. Given no choice, I tend towards the one that makes fast code. Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809142240.RAA09355>