[U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday, November 17, 2010 14:53:33 Sebastien Carlier wrote:
> On 2010-11-17 13:06:49, Mike Frysinger wrote:
> > On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> > > The size increase you noted seems to completely go away when adding
> > > --gc-sections to LDFLAGS, but this option apparently brings its own
> > > 
> > > issues when the linker discards important unreferenced bits:
> > >     http://www.mail-archive.com/u-boot at lists.denx.de/msg41762.html
> > >     http://www.mail-archive.com/u-boot at lists.denx.de/msg42063.html
> > > 
> > > These problems can be fixed within linker scripts, but I think it might
> > > be safer to use --gc-sections for diagnostic purposes only...
> > 
> > it's really not that hard to fix things to work with --gc-sections (ive
> > been using it on Blackfin for literally years at this point).  people
> > really should be driving to have that supported everywhere.
> 
> Maybe I was being overly conservative.  With --gc-sections, I assume the
> linker only needs to be told to keep any section that has no external
> references to it, which would only include startup code and reset
> vectors.  Is that accurate?

yes

> Is there any other case that may need special handling?

the u-boot command handling is a bit funky and needs handling, but that was 
implemented years ago in common code, so ports need not worry about it

> I suppose -ffunction-sections and -fdata-sections increase compile time;
> are they worth it in practice?

in practice, the difference is irrelevant.  for the bf548-ezkit build (a 
fairly large image -- in the 512KiB range), i run on a dual core system:
	git clean -x -d -q
	time make -s -j2 bf548-ezkit

with the section flags, i get ~5.7 seconds.  without, i get ~5.1 seconds.

> The few cases I have seen involved whole
> objects being unused, so just --gc-sections would deal with them.

it also takes care of unused common code and library functions.  for Blackfin 
systems, i provide the full common GPIO API in one file, but any local funcs 
that no one uses all get discarded.

it also keeps down horrible ifdef messes where the only point point would be 
to move gcc's DCE step to CPP.

again, to refer to the bf548-ezkit, i get ~10KB of .text removed by this alone
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101117/37272b9c/attachment.pgp