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-Options -Kevin -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
