[coreboot] [PATCH]Include headers instead of sources in romstage, part 1/many
kevin at koconnor.net
Sat May 8 18:40:27 CEST 2010
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
> 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:
More information about the coreboot