Yeah, that makes sense. We don't really have subsystems with local symbols. That said, is it faster to incremental link strip and then finish the link? I'm just curious if there are any symbols that we can automatically strip.
Then again, I build debug most of the time and you wouldn't want to strip that, so... Nate On Mon, Jun 9, 2008 at 10:50 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > I've done some reading online and it doesn't appear that incremental > linking will cut down on the link time much at all. Doing it in > smaller chunks doesn't help if all the symbols end up being exported > at the end. The two ways to speed it up are to (a) not include any > debugging information (remove the -g flag) or (b) build various > pieces as shared libraries and link them dynamically at runtime. (a) > isn't probably useful for your purposes and (b) increases the > difficultly of debugging the code substantially as well as requires > various pieces of the simulator to be completely independent. Either > way I doubt it's worth the effort. > > Ali > > > On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: > >> Few comments. >> 1) I like this idea. >> 2) Linux explicitly exports symbols outside of an object. This seems >> like it would be a pain. >> 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove >> these with strip. >> 4) It shouldn't be hard to get SCons to support this sort of thing. >> >> Nate >> >> On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black <[EMAIL PROTECTED]> >> wrote: >>> Is there some way we can make m5 link incrementally, or in >>> other words >>> link subsystems together independently and then as units with each >>> other? The final linking step seems to take a long time with ld at >>> 100% >>> cpu usage. That makes sense when you consider it's linking a screen >>> and >>> a half of object files. Breaking things into smaller ".o"s that >>> then get >>> linked would help because a lot of the symbols would get resolved >>> locally and wouldn't cause a search over the all the other object >>> modules. Even better would be to restrict the set of symbols that get >>> linked between subsystems so the search is over a smaller space as >>> well, >>> as apposed to just being done fewer times, but I don't know how we >>> could >>> do that without specializing to one set of tools or using obscure >>> features like anonymous namespaces. Anonymous namespaces might not >>> even >>> help because they hide symbols by putting them in generated unique >>> namespaces, but the linker probably doesn't know that and would go >>> through them all the time anyway. This isn't broken perse, but >>> since you >>> have to link every time you build and I'm on a slower machine it's >>> very >>> annoying. >>> >>> Gabe >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
