[PATCH] RFC: garbage collect unused code/data?

Rob Landley rob at landley.net
Sat Apr 8 02:01:58 UTC 2006


On Friday 07 April 2006 3:28 am, Denis Vlasenko wrote:
> On Thursday 06 April 2006 19:00, Rich Felker wrote:
> > On Thu, Apr 06, 2006 at 05:28:59PM +0300, Denis Vlasenko wrote:
> > > On Wednesday 05 April 2006 19:30, David Daney wrote:
> > > > Note that in the case of mips, the linker has had the --gc-sections
> > > > option for quite some time now, but has only had working support
> > > > since about 'GNU ld version 2.16.91 20050817'.  The first official
> > > > binutils release that will work with --gc-sections is 2.17.
> > > >
> > > > Probably the best way to handle it would be through some sort of
> > > > configure option (perhaps in conjunction with the linker test).  That
> > > > way it could be turned off if someone was using a broken tool chain.
> > >
> > > Why do you want it configurable? Dropping a few unused code fragments
> > > can never hurt...
> > >
> > > I think that with checks for "known good" gcc and ld versions
> > > (arch-dependent) it could be enabled unconditionally.
> >
> > It should be configurable so the ELF users can disable it and see what
> > bloat they still need to fix.
>
> Why do you want to fix it manually when toolchain is able
> to do it automatically for you?

Because the toolchain can only do it automatically for you if you use ELF (and 
if you use a new enough compiler version at that).

It is possible to not use ELF.  Look at CONFIG_BINFMT_FLAT in the linux kernel 
for an example.

> I am not a big fan of splitting 
> few .c files into zillion of one-function-per-file .c files
> (or preprocessor magic which does the same with #ifdefs),
> are you?

No, but we need it anyway.

It's also nice not to compile stuff we don't need, although it would be nicer 
if dependencies could be properly autodetected.  (We need to tackle this for 
make standalone anyway, so...)

> OTOH I understand that non-ELF targets may still need to do
> those tricks... oh well.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list