[U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions

Joakim Tjernlund joakim.tjernlund at transmode.se
Wed Dec 8 15:44:12 CET 2010


Wolfgang Denk <wd at denx.de> wrote on 2010/12/08 15:23:17:
>
> Dear Joakim Tjernlund,
>
> In message <OF280890AF.2970DA02-ONC12577F3.004474F0-C12577F3.0044D6E5 at transmode.se> you wrote:
> >
> > > oh, and this does shrink the final u-boot a little, so that's good
> > > -mike
> >
> > Nice, over the last years I have noticed that u-boot has grown a lot.
> > I had to disable a few non essential commands to make it it fit.
> >
> > Does anyone else share my concern about the rapid growth of u-boot?
>
> I do, and always did. It's mainly features that drive the code size.
> Some recent changes (gc-sections on PPC) help a bit. And users
> submitting optimizations like above.

Yes, but I don't see any discussion about it. Just the occasional improvement
that pop by every now and then.

I got my own theory were some of the growth come from: string literals
Especially when using them in tables:
static struct {
		ulong mask;
		char *desc;
	} bits[] = {
		{
		RSR_SWSR, "Software Soft"}, {
		RSR_SWHR, "Software Hard"}, {
		RSR_JSRS, "JTAG Soft"}, {
		RSR_CSHR, "Check Stop"}, {
		RSR_SWRS, "Software Watchdog"}, {
		RSR_BMRS, "Bus Monitor"}, {
		RSR_SRS,  "External/Internal Soft"}, {
		RSR_HRS,  "External/Internal Hard"}
	};
Obviously the strings consume space, but there is an hidden extra cost too:
each string gets an fixup entry(4 bytes) and a GOT entry(4 bytes) too.

  Jocke



More information about the U-Boot mailing list