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.
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? ;-)
> 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.
-- Linuxcare. Support for the Revolution.- 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