On Sat, May 08, 2010 at 06:22:54PM +0200, Stefan Reinauer wrote:
On 5/8/10 5:56 PM, Kevin O'Connor wrote:
I think coreboot should try to avoid using .a files.
The latest version of gcc (v4.5) contains the -flto feature. This can provide significant benefits to coreboot code generation because it allows the entire romstage (and ramstage) to be analyzed as a whole. The resulting binaries are significantly smaller because unused code can be eliminated and more functions can be inlined. Unfortunately, the standard linker can't handle -flto with .a files.
The reason we used .a files to begin with was because the linker can smartly drop unused objects files "linked" into a static library, significantly decreasing code size.
Yeah, but I've not had much luck with that optimization because it's too easy to inadvertently pull in .o files. I've had more success with enabling -ffunction-sections / -fdata-sections and giving ld the --gc-sections option.
Going to -flto introduces one code size reduction mechanism by rendering another one unusable. That's only half-baked, especially since many optimizations making -flto useful are still known broken in gcc 4.5. We should keep this in mind. Last time I checked -flto on a coreboot image it would not gain more than 1-2kb on a 1MB image. Didn't benchmark the 4.5 release yet though.
I use -fwhole-program in seabios and find it quite useful. I haven't done much with -flto, but it is supposed to allow -fwhole-program without having to completely restructure the build process. It's more than just a size optimization, though I suspect that's the biggest impact coreboot would see.
Being curious: Will gold cope with .a files and flto?
Yes (according to the gcc documentation).
See the -flto description at:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Optimize-Options.html#Optimize-O...
-Kevin