In the meantime, this should circumvent command line problems during linking:
https://gem5-review.googlesource.com/#/c/2780/ Gabe On Thu, Apr 13, 2017 at 1:58 PM, Gabe Black <[email protected]> wrote: > For reference, here's somebody also trying to figure out how to get '-r' > working in scons from 9 years ago. > > http://scons-users.scons.narkive.com/OJRUXpKC/partial-linking-with-scons > > I don't think they got a great answer, but it's at least something. > > Gabe > > On Thu, Apr 13, 2017 at 1:52 PM, Gabe Black <[email protected]> wrote: > >> Yeah, I think the problem could have been using .a files. There's a thing >> where the linker doesn't go back and look at stuff in an archive it's >> already processed if it needs to, and will just error out due to unresolved >> symbols. You have to solve that by putting the .as on the command line >> multiple times so they'll be reprocessed, and if there are lots of >> interdepedencies that can be difficult. I don't know if scons has built in >> support for something like -r, but I don't think that has the same problem. >> >> Gabe >> >> On Thu, Apr 13, 2017 at 1:47 PM, Steve Reinhardt <[email protected]> >> wrote: >> >>> I don't exactly remember why I thought it was hard... I probably only >>> spent >>> an hour or so looking at it before I realized it would take more time >>> than >>> I had (which wasn't much). Maybe I was overly pessimistic, I don't know. >>> I >>> was thinking of trying to do something implicit, e.g., if you could just >>> hack SourceFile to add objects to a per-"module" list (base, sim, dev, >>> etc.) instead of a global list then you wouldn't have to touch any of the >>> other SConscript files. >>> >>> As far as the dependencies that Jason points out, I don't think they >>> should >>> be that problematic. It's not that we want to compile everything in >>> 'base' >>> using only the code in 'base'; we can compile the objects the same way >>> we've always compiled the objects. The only difference is that we want to >>> inject an intermediate linking step. We would still have to do all the >>> code >>> generation (ISA headers, debug headers, etc.) up front. >>> >>> Moving to the point where some of these intermediate objects/libraries >>> are >>> ISA-independent would be awesome, but I see that as a separate >>> step---seems >>> like too much to bite off to do that at the same time. >>> >>> Steve >>> >>> >>> On Thu, Apr 13, 2017 at 1:38 PM, Gabe Black <[email protected]> >>> wrote: >>> >>> > Yeah, I'm not surprised about how interlinked everything is. I looked >>> into >>> > what it would take to build multiple ISAs in at the same time a long >>> time >>> > ago, and it would have been a huge undertaking for the same reason. >>> > >>> > I think there are (at least) two different ways to do an incremental >>> link. >>> > First, we could create .a files with different groups of .o files, and >>> then >>> > link them together at the end. That might even be supported by scons, >>> but >>> > then ordering things correctly is a pain. This might be what you were >>> > having trouble with. >>> > >>> > Another option is to use the -r or --relocatable flag on the linker >>> which >>> > makes it generate a file which can be used as an input to a subsequent >>> run >>> > of the linker. That could be used to gather up clusters of .o files and >>> > generate another .o, and I think would alleviate the ordering issue. >>> > >>> > I was also thinking of doing something simple, like grouping things per >>> > SConscript processed or something like that. That wouldn't be perfect, >>> but >>> > it would generally isolate things into relatively small clumps which >>> would >>> > get the job done. Explicitly grouping things would be give you better >>> > groups I think, but it would be more cumbersome to manage. >>> > >>> > Gabe >>> > >>> > On Thu, Apr 13, 2017 at 1:20 PM, Jason Lowe-Power <[email protected] >>> > >>> > wrote: >>> > >>> > > Hi Gabe, >>> > > >>> > > Just today I was looking at incremental linking and breaking gem5 >>> into >>> > > "components". I was specifically looking at it as a stepping stone >>> to use >>> > > Bazel (https://bazel.build/) as the build system instead of Scons. >>> On a >>> > > side note, it looks like Bazel has a lot of features that we could >>> take >>> > > advantage of. There are a couple of downsides, but that's a >>> conversation >>> > > for another time. >>> > > >>> > > What makes it hard to break gem5 into components is that everything >>> is >>> > very >>> > > tightly coupled. For instance, I was trying to compile just "base" >>> > thinking >>> > > it was the simplest. But it depends on debug (which is everywhere, >>> and >>> > > nowhere), serializable (which depends on stuff in sim/), the event >>> queue >>> > > logic, and some stuff in ext/! Similarly, almost everything somehow >>> > depends >>> > > on the ISA. There are also a number of circular dependencies. It's >>> far >>> > from >>> > > straightforward to get any one directory to compile without all of >>> the >>> > > others. >>> > > >>> > > Overall, I think what we would need to do to make this happen is >>> > completely >>> > > reorganize gem5's source. I think this would be good in the long >>> run, but >>> > > it would take me at least 2-4 weeks. Maybe I'm slower than others, >>> > though. >>> > > There is a huge downside to this, too. All internal patches would be >>> very >>> > > hard to apply after making a change like this. >>> > > >>> > > Just a few thoughts. >>> > > >>> > > Cheers, >>> > > Jason >>> > > >>> > > PS: For error 127, I would just do something hacky, personally. In >>> the >>> > long >>> > > run, we should do something to make gem5 more modular and move away >>> from >>> > > SCons. But I don't think it's worth it just for this one issue. >>> > > >>> > > On Thu, Apr 13, 2017 at 3:10 PM Gabe Black <[email protected]> >>> wrote: >>> > > >>> > > > Ok, I think we're all pretty much in agreement then, since I was >>> > thinking >>> > > > about incremental linking too. What about it looked non-trivial, >>> > Steve? I >>> > > > haven't dug into it very much yet, but as long as it doesn't turn >>> into >>> > > too >>> > > > much of an ordeal I'd like to take care of it. >>> > > > >>> > > > Potentially less ideal solutions which might also be easier would >>> be to >>> > > > override the env['SPAWN'] setting so that it would skip going >>> through >>> > the >>> > > > shell if it could, and seeing if we could load some things that are >>> > > > currently on the command line from files of options/input files. >>> > > > >>> > > > I think the reason scons is purposefully going through the shell >>> is to >>> > > make >>> > > > things like redirection, etc., work. We take advantage of that in >>> at >>> > > least >>> > > > one place I've seen, but it might be feasible to remove that and >>> > > specialize >>> > > > env['SPAWN'] in a way that breaks redirection but allows >>> arbitrarily >>> > long >>> > > > command lines. >>> > > > >>> > > > But I still think incremental linking would be nicer for a number >>> of >>> > > other >>> > > > reasons, as long as it's implementable. >>> > > > >>> > > > Gabe >>> > > > >>> > > > On Thu, Apr 13, 2017 at 10:16 AM, Steve Reinhardt < >>> [email protected]> >>> > > > wrote: >>> > > > >>> > > > > #3 is the traditional solution :) >>> > > > > >>> > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < >>> > > > > [email protected]> wrote: >>> > > > > >>> > > > > > There are a three ways to fix this as far as I can tell: >>> > > > > > >>> > > > > > 1) Modify our Scons setup to use staged linking. >>> > > > > > 2) Recompile your kernel to allow for larger ARG_MAX. >>> > > > > > 3) Modify your paths etc to avoid long names >>> > > > > > >>> > > > > > 1) seems to be the best option, but seems like it could be a >>> lot of >>> > > > work. >>> > > > > > >>> > > > > > -----Original Message----- >>> > > > > > From: gem5-dev [mailto:[email protected]] On Behalf Of >>> > Gabe >>> > > > > Black >>> > > > > > Sent: Thursday, April 13, 2017 9:50 AM >>> > > > > > To: gem5 Developer List <[email protected]> >>> > > > > > Subject: Re: [gem5-dev] scons question >>> > > > > > >>> > > > > > Oh, I bet you're right. They actually spawn something like >>> 'sh', >>> > > '-c', >>> > > > ' >>> > > > > > '.join(args), and I bet sh (which is symlinked to /bin/bash) is >>> > > blowing >>> > > > > up >>> > > > > > because the command line is very long. I remember my terminal >>> > asking >>> > > > if I >>> > > > > > really wanted to copy/paste something like 129K characters when >>> > > trying >>> > > > to >>> > > > > > copy the command line to run it outside of scons. >>> > > > > > >>> > > > > > Now to figure out how to fix it... >>> > > > > > >>> > > > > > On Thu, Apr 13, 2017 at 8:02 AM, Beckmann, Brad < >>> > > [email protected] >>> > > > > >>> > > > > > wrote: >>> > > > > > >>> > > > > > > Have you investigated the length of the linker command when >>> > > building >>> > > > > > > from outside the gem5 directory? In the past, we've seen >>> that >>> > > > > > > mysterious error >>> > > > > > > 127 because the linker stage uses a shell command length that >>> > > exceeds >>> > > > > > > the length supported by the OS. 64KB I believe. I suspect >>> that >>> > > the >>> > > > > > > filenames are longer when building outside of gem5, thus it >>> only >>> > > > > > > happens in that situation. The linker command may be shorter >>> > using >>> > > > > > clang as well. >>> > > > > > > >>> > > > > > > Brad >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > -----Original Message----- >>> > > > > > > From: gem5-dev [mailto:[email protected]] On Behalf >>> Of >>> > > Gabe >>> > > > > > > Black >>> > > > > > > Sent: Thursday, April 13, 2017 1:53 AM >>> > > > > > > To: gem5 Developer List <[email protected]> >>> > > > > > > Subject: [gem5-dev] scons question >>> > > > > > > >>> > > > > > > Hi folks. I'm fighting with a very confusing problem with >>> scons >>> > at >>> > > > the >>> > > > > > > moment. For reasons I haven't determined, when I have things >>> set >>> > up >>> > > > to >>> > > > > > > build when scons is run from outside the gem5 directory >>> (using >>> > -C), >>> > > > it >>> > > > > > > fails the final linker step with error 127 and no other >>> output >>> > 100% >>> > > > of >>> > > > > > > the time. If I run from within the gem5 directory everything >>> > works >>> > > > > fine. >>> > > > > > > >>> > > > > > > I did some reading, and bash reports error 127 when it can't >>> find >>> > > the >>> > > > > > > command you asked it to run. To determine if that might be >>> the >>> > > > > > > problem, I modified scons to run "which" on each command it >>> was >>> > > about >>> > > > > > > to spawn before it did, to make sure it resolved to >>> something. >>> > That >>> > > > > > > worked just fine. If I run the command manually, it returns >>> exit >>> > > code >>> > > > > > > 0. If I take the environment scons tries to run g++ under and >>> > > > > > > partially duplicate that with a script and env -i, it still >>> > > succeeds. >>> > > > > > > >>> > > > > > > If I run with clang instead of g++, I get the same behavior >>> which >>> > > > > > > makes me think it's not g++ doing something weird, it's >>> scons. I >>> > > > can't >>> > > > > > > for the life of me figure out what though, and I can't seem >>> to >>> > get >>> > > > any >>> > > > > > > information to work with other than this mysterious error >>> 127. >>> > > > > > > >>> > > > > > > If any of you have any idea why it's doing what it's doing, >>> or if >>> > > > > > > there's any information I can gather that might help, I >>> would be >>> > > very >>> > > > > > > happy to hear it. >>> > > > > > > >>> > > > > > > Gabe >>> > > > > > > _______________________________________________ >>> > > > > > > gem5-dev mailing list >>> > > > > > > [email protected] >>> > > > > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > > > > > _______________________________________________ >>> > > > > > > gem5-dev mailing list >>> > > > > > > [email protected] >>> > > > > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > > > > _______________________________________________ >>> > > > > > gem5-dev mailing list >>> > > > > > [email protected] >>> > > > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > > > > _______________________________________________ >>> > > > > > gem5-dev mailing list >>> > > > > > [email protected] >>> > > > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > > > > >>> > > > > _______________________________________________ >>> > > > > gem5-dev mailing list >>> > > > > [email protected] >>> > > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > > > >>> > > > _______________________________________________ >>> > > > gem5-dev mailing list >>> > > > [email protected] >>> > > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > _______________________________________________ >>> > > gem5-dev mailing list >>> > > [email protected] >>> > > http://m5sim.org/mailman/listinfo/gem5-dev >>> > > >>> > _______________________________________________ >>> > gem5-dev mailing list >>> > [email protected] >>> > http://m5sim.org/mailman/listinfo/gem5-dev >>> > >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >>> >> >> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
