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.
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. Being curious: Will gold cope with .a files and flto? -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
