Graham Stoney wrote:
> I'm definitely with you on this one. Using ld -r in intermediate
> stages is defeating the linker's natural ability to exclude unused
> objects. My patch achieves a similar effect by allowing the linker to
> exclude unused functions, but it does so in a very torturous way. I'd
> prefer to have both .a's for wholesale dead object elimination _and_
> -ffunction-sections for elimination of any remaining dead functions.
Jamie Lokier writes:
> OTOH .a's are slower than ld -r. They don't save any I/O: all the
> enclosed object files have to be duplicated until the final link anyway.
> ld -r removes duplicate symbols and debugging information, which makes
> the .o files smaller than the corresponding .a files and faster to read.
Even if Jamie's theoretical assertion that using 'ar' is slower overall than
'ld -r' in the kernel build was true, the difference is in the noise. I just
tried recompiling the exact same kernel with both, and the elapsed compilation
times are essentially identical. In fact, 'ar' came out marginally faster, but
the difference is pure noise because the intermediate library build and final
link times are small compared to the overall compile time. Of course, the
resulting vmlinux built with 'ar' is (slightly) smaller, every time.
With 'ar':
% time make vmlinux
221.170u 18.560s 4:29.38 88.9% 0+0k 0+0io 360058pf+0w
greyham@brixi% powerpc-linux-size vmlinux
text data bss dec hex filename
851068 70500 99320 1020888 f93d8 vmlinux
With 'ld -r':
% time make vmlinux
220.500u 17.340s 4:39.54 85.0% 0+0k 0+0io 325884pf+0w
% powerpc-linux-size vmlinux
text data bss dec hex filename
864624 70516 99364 1034504 fc908 vmlinux
Also, bear in mind that using 'ar' would allow us to eliminate lots of
"ifdef CONFIG_..." ugliness from Makefiles. Don't do by hand what the linker
can do for us automatically.
For anyone interested in pursuing this, my patch for building using 'ar' is
available at:
http://members.xoom.com/greyhams/linux/patches/2.2/arbuild.patch
It should apply reasonably cleanly either with or without my earlier dead
function optimisation patch. You need both to get the smallest result due to
constant string handling issues in gcc 2.95.2.
Enjoy,
Graham
-- Graham Stoney Principal Hardware/Software Engineer Canon Information Systems Research Australia Ph: +61 2 9805 2909 Fax: +61 2 9805 2929- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:14 EST