[coreboot] [PATCH]Include headers instead of sources in romstage, part 1/many

[Kevin O'Connor]

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