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
