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.
The linker has the same amount of input and output. With appropriate
design it should be able to link the many-sections objects in the same
amount of time, surely. Right now it's taking 32 seconds, as against
0.13 seconds for non-function-sections objects.
Given that a 2.2 compile takes two minutes with gcc 2.7.2 (three minutes
with 2.96. - grump), adding another thirty seconds to that is a but
rude, particularly as most builds don't involve a global recompile.
I assume there's something quadratic happening in the linker. It would
be great if the ld team could fix this, because Graham's trick would be
useful for many more things than just the kernel. Hell, make it the
default in gcc's specs file.
Can --gc-sections be persuaded to tell the programmer what functions it
is removing? That could be useful information.
Does it work with C++ static ctors? To test I compiled this:
#include <iostream.h>
class thing
{
public:
thing()
{
cout << "thing::thing()\n";
}
};
thing t;
main()
{}
static void remove_me(void)
{}
with g++ -ffunction-sections -Wl,--gc-sections t.cc and it didn't remove
'remove_me'. Something dumb, probably.
> > I would suggest that you make '-ffunction-sections/--gc-sections' _not_
> > be the default behaviour - it's a concern that you're treading rarely
> > travelled code paths through the compiler and linker. Perhaps add an
> > experimental CONFIG_GC_FUNCTIONS?
>
> No. No. Please make this the default. If you have a CONFIG option, then
> you have to keep all the other ifdefs you talk about removing above.
> Besides that, Grahams's patch is one of the neatest binutils tricks I've
> seen for a while. Please make these code paths heavily travelled. :-)
I like that attitude. I'm too conservative. Have to fix the linkage
time though.
-- -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