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
