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
