Re: [gem5-dev] scons question
;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 <gabebl...@google.com> >>> 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 < >>> ste...@gmail.com> >>> > > > wrote: >>> > > > >>> > > > > #3 is the traditional solution :) >>> > > > > >>> > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < >>> > > > > anthony.gutier...@amd.com> wrote: >>> > > > > >>> > > > > > There are a three ways to fix this as far as I can tell: >>> > > > > >
Re: [gem5-dev] scons question
; > > 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 <gabebl...@google.com> >> 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 <ste...@gmail.com >> > >> > > > wrote: >> > > > >> > > > > #3 is the traditional solution :) >> > > > > >> > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < >> > > > > anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of >> > Gabe >> > > > > Black >> > > > > > Sent: Thursday, April 13, 2017 9:50 AM >> > > > > > To: gem5 Developer List <gem5-dev@gem5.org> >> > > > > > 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
Re: [gem5-dev] scons question
lower 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 <gabebl...@google.com> > 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 <ste...@gmail.com> > > > > wrote: > > > > > > > > > #3 is the traditional solution :) > > > > > > > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < > > > > > anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of > > Gabe > > > > > Black > > > > > > Sent: Thursday, April 13, 2017 9:50 AM > > > > > > To: gem5 Developer List <gem5-dev@gem5.org> > > > > > > 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 < > > > brad.beckm...@amd.com > > > > > > > > > > > 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
Re: [gem5-dev] scons question
deal 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 <ste...@gmail.com> > > > wrote: > > > > > > > #3 is the traditional solution :) > > > > > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < > > > > anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of > Gabe > > > > Black > > > > > Sent: Thursday, April 13, 2017 9:50 AM > > > > > To: gem5 Developer List <gem5-dev@gem5.org> > > > > > 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 < > > brad.beckm...@amd.com > > > > > > > > > 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:gem5-dev-boun...@gem5.org] On Behalf Of > > Gabe > > > > > > Black > > > > > > Sent: Thursday, April 13, 2017 1:53 AM > > > > > > To: gem5 Developer List <gem5-dev@gem5.org> > > > > > > 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 >
Re: [gem5-dev] scons question
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 <ja...@lowepower.com> 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 <gabebl...@google.com> 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 <ste...@gmail.com> > > wrote: > > > > > #3 is the traditional solution :) > > > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < > > > anthony.gutier...@amd.com> 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 coul
Re: [gem5-dev] scons question
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 <gabebl...@google.com> 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 <ste...@gmail.com> > wrote: > > > #3 is the traditional solution :) > > > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < > > anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > > Black > > > Sent: Thursday, April 13, 2017 9:50 AM > > > To: gem5 Developer List <gem5-dev@gem5.org> > > > 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 <brad.beckm...@amd.com > > > > > 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. > > > > > >
Re: [gem5-dev] scons question
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 <ste...@gmail.com> wrote: > #3 is the traditional solution :) > > On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < > anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > Black > > Sent: Thursday, April 13, 2017 9:50 AM > > To: gem5 Developer List <gem5-dev@gem5.org> > > 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 <brad.beckm...@amd.com> > > 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > > > Black > > > Sent: Thursday, April 13, 2017 1:53 AM > > > To: gem5 Developer List <gem5-dev@gem5.org> > > > 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 > >
Re: [gem5-dev] scons question
#3 is the traditional solution :) On Thu, Apr 13, 2017 at 10:13 AM, Gutierrez, Anthony < anthony.gutier...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black > Sent: Thursday, April 13, 2017 9:50 AM > To: gem5 Developer List <gem5-dev@gem5.org> > 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 <brad.beckm...@amd.com> > 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > > Black > > Sent: Thursday, April 13, 2017 1:53 AM > > To: gem5 Developer List <gem5-dev@gem5.org> > > 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 > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] scons question
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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black Sent: Thursday, April 13, 2017 9:50 AM To: gem5 Developer List <gem5-dev@gem5.org> 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 <brad.beckm...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > Black > Sent: Thursday, April 13, 2017 1:53 AM > To: gem5 Developer List <gem5-dev@gem5.org> > 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 > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] scons question
Agreed. I actually looked into doing this once briefly (primarily to reduce link time), but it looked like it wasn't going to be trivial, so I punted. On Thu, Apr 13, 2017 at 10:09 AM, Andreas Hansson <andreas.hans...@arm.com> wrote: > The best solution, in my view, would be to link the various subdirectories > into static libraries, libbase.a etc, and do so independent of the ISA > that is being built. Everything besides the arch and dev tree should then > be able to be built once, and the linking also ends up being hierarchical. > > Andreas > > On 13/04/2017, 17:50, "gem5-dev on behalf of Gabe Black" > <gem5-dev-boun...@gem5.org on behalf of gabebl...@google.com> wrote: > > >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 <brad.beckm...@amd.com> > >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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe > >>Black > >> Sent: Thursday, April 13, 2017 1:53 AM > >> To: gem5 Developer List <gem5-dev@gem5.org> > >> 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 > >> gem5-dev@gem5.org > >> http://m5sim.org/mailman/listinfo/gem5-dev > >> ___ > >> gem5-dev mailing list > >> gem5-dev@gem5.org > >> http://m5sim.org/mailman/listinfo/gem5-dev > >___ > >gem5-dev mailing list > >gem5-dev@gem5.org > >http://m5sim.org/mailman/listinfo/gem5-dev > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] scons question
The best solution, in my view, would be to link the various subdirectories into static libraries, libbase.a etc, and do so independent of the ISA that is being built. Everything besides the arch and dev tree should then be able to be built once, and the linking also ends up being hierarchical. Andreas On 13/04/2017, 17:50, "gem5-dev on behalf of Gabe Black" <gem5-dev-boun...@gem5.org on behalf of gabebl...@google.com> wrote: >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 <brad.beckm...@amd.com> >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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe >>Black >> Sent: Thursday, April 13, 2017 1:53 AM >> To: gem5 Developer List <gem5-dev@gem5.org> >> 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 >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev >> ___ >> gem5-dev mailing list >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev >___ >gem5-dev mailing list >gem5-dev@gem5.org >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
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 <brad.beckm...@amd.com> 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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black > Sent: Thursday, April 13, 2017 1:53 AM > To: gem5 Developer List <gem5-dev@gem5.org> > 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 > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] scons question
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:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black Sent: Thursday, April 13, 2017 1:53 AM To: gem5 Developer List <gem5-dev@gem5.org> 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
