Re: Reducing debuginfo size by removing unneeded includes

[Arnaldo Carvalho de Melo]

Em Mon, Feb 18, 2008 at 02:12:01PM +0100, Andi Kleen escreveu:
> Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> writes:
> >
> > [acme@doppio net-2.6]$ l /tmp/sys_ia32.o.before /tmp/sys_ia32.o.after
> > -rw-rw-r-- 1 acme acme 185240 2008-02-06 19:19 /tmp/sys_ia32.o.after
> > -rw-rw-r-- 1 acme acme 248328 2008-02-06 19:00 /tmp/sys_ia32.o.before
> >
> > 	Almost 64KB only on this object file!
> 
> Just FYI, newer gcc does this in theory automatically when you specify 
> 
> -feliminate-unused-debug-types -feliminate-unused-debug-symbols
> 
> But in my tests on gcc 4.1 / gcc 4.2 it doesn't seem to make any difference
> currently :/ Not sure what is wrong. 
> 
> There is also -feliminate-dwarf2-dups, but it seems to even increase
> obj dir size. Also -feliminate-dwarf2-dups seems to generate a lot of 
> 
> WARNING: vmlinux.o (.gnu.linkonce.wi.mmzone.h.97561702): unexpected section name.
> The (.[number]+) following section name are ld generated and not expected.
> Did you forget to use "ax"/"aw" in a .S file?
> Note that for example <linux/init.h> contains
> section definitions for use in .S files.
> 
> etc. warnings But the kernel builds fine even with those warnings.
> 
> Still if you just want to shrink objdir size then figuring out
> what's wrong with these options and then specifying them would be 
> probably the best strategy than to try to do it all manually.
> 
> That said removing unused includes is of course a valuable
> clean up by itself, I'm just not sure it's the best way to get
> smaller object dirs.

I found just it to be another reason for cleaning up the includes hell,
but I agree completely that the correct solution is for gcc to do the
right thing and eliminate unused debug types.

Thanks for showing that there is support for that in latest gccs, I'll
try to use it when I get back to looking at this issue.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/