Alan Modra wrote:
>
> On Fri, 21 Apr 2000, Andrew Morton wrote:
>
> > Alan Modra wrote:
> > >
> > > > Interesting that 'ld --gc-sections' takes about 15x longer than normal.
> > >
> > > Not that surprising. There's a lot more than 15x as many linker sections
> > > to be processed.
> >
> > Standing back and squinting, I don't see a reason why this should be.
>
> To see where the the extra processing time is coming from, compile with
> -ffunction-sections, -fdata-sections, but link _without_ --gc-sections.
> I suspect this will be comparable to the normal link time, indicating the
> garbage collecting pass is the culprit.
First thing I tried! With or without --gc-sections it's 32 seconds.
> Having a look at the gc code, I see there is a FIXME in
> binutils/bfd/elflink.h:elf_gc_mark regarding not reading in all the relocs
> for each section.
>
> > Can --gc-sections be persuaded to tell the programmer what functions it
> > is removing? That could be useful information.
>
> Probably. Want to send me a patch? ;-)
I hate that answer :)
Actually, the FSF copyright assignment would give my employer
conniptions. This put me off last time I was diddling the compiler.
Something small like this would be OK though. Give me a few days.
Does :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src get me HJ's stuff?
> > Does it work with C++ static ctors? To test I compiled this:
>
> g++ uses collect2, which as far as I can see, doesn't pass --gc-sections
> on to ld.
Does this rule out gc for C++?
-- -akpm-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST