This check used uname to determine if scons was running on macos, and
then a fairly elaborate check to see if the version was above 9, and if
the hardware supported 64 bit. I think at this point it's safe to assume
both that we're at least at macos 10 which is 19 years old, and that Mac
hardware supports 64 bit.
Change-Id: Ice66df2530bbcc929d3a37e7679634b75ba7b860
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40857
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This avoids boilerplate where we check to see if flag X is supported,
and if so then set flag X. Since there are shared and static versions of
the linker flags but we only explicitly check the static ones, this
change also adds a parameter to CheckLinkFlag to set both flavors. This
defaults to true since I assume most of the time linking flags will
apply to both.
Change-Id: I983222169e9835aeb98570362f7004e2ef0240d0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40855
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If supported this will compress the debug information in object files,
libraries, and binaries. This decreases the size of the build/ARM
directory from 11GB to 7.2GB.
Because the benefit of this mechanism depends on the performance and
capacity of the build machine's storage, it can be disabled with the
--no-compress-debug scons flag. For instance if your storage is very
fast, writing out a larger binary may take less time than compressing
that same number of bytes, plus the time to write out the smaller
file.
This feature seems to make our presubmit test machine run out of memory
when trying to build gem5, and so is disabled in the testing scripts.
Change-Id: I71919062d23742b7658918b0fa9c4d91d0521fbf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40715
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SCons has a system of "tools", which basically detect versions of build
tools (compilers, linkers, etc) and set up an environment with the
appropriate build variable substitutions for that tool to be used.
For instance, there would be a "tool" for gcc, and it would detect if
gcc is present on the system, and if so would set the "CC" variable to
"gcc". An actually tool as defined by SCons would be a lot more
sophisticated than that and set more variables, but that's the basic
idea.
To help modularize the gem5 SConstruct file, I moved code which would
set up git commit hooks into a "tool" which helped modularize it and
reduce the size of SConstruct.
This isn't quite right since, while the code does detect if git was
used to check out the source (if there is a .git file at the root), it
doesn't really modify the environment at all. It will also be invoked
every time any environment is set up, although right now that will only
be the DefaultEnvironment, what's used when loose functions like
Builder or Command are called with, and the "main" environment which
all the others are Clone-d from.
Normally, when SCons sets up a new environment, either implicitly or
when Environment() is called, it sets up a bunch of built in tools
which are fixed within SCons itself. If you want, you can add a "tools"
argument to Environment (or to the DefaultEnvironment() function) which
will replace that list of tools. That can be used to make an
environment use the new "git" tool, but it isn't automatic.
SCons also lets you override default tools by creating your own with
the same name as the default. To make loading the git tool automatic,
I added an override "default" tool which, in addition to setting some
defaults which should apply to all environments, also pulled in other
tools, at that time "git" and "mercurial" (RIP).
Unfortunately, that meant that today, apparently particularly with
SCons version 4, *any* Environment would pull in "git", and all of
"git"'s dependencies, even if SCons wasn't set up enough for those to
work.
To break that dependency, this change stops the default tool from
automatically loading the git tool, although it does continue to set
other defaults which have very minimal external dependencies. When
creating the "main" Environment in the SConstruct, the "git" tool is
now added in explicitly. Since the list of tools replaces the original
and doesn't extend it, we have to add in "default" explicitly as well.
Really, the "git" tool should be converted from the tool interface into
something more appropriate, like perhaps a small module under
site_scons which site_init.py can import and call. When that happens,
main can be declared like normal again.
While making this change, I also got rid of a few nonstandard additions
to the main environment that were little used and not really necessary.
When reading the SConstruct, it wasn't very obvious where those extra
values were coming from, and they didn't really add any value.
Change-Id: I574db42fc2196bf62fc13d6754357c753ceb9117
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38616
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add some more stringent Python tests that ensure that we can link with
and run applications that embed Python. This is implemented by running
building a small c++ program that embeds Python using PyBind11. The
program is run by the build system and prints the version of the
Python interpreter. The version information is then used by the build
system to ensure that the installed version is supported.
Change-Id: I727e0832f171362f5506247c022bea365068a0f6
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36383
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This matches what's documented elsewhere. We *need* version 3.4 to
support c++14, but we support only as far back as 3.9. Also, the
argument to set c++14 as the standard is different in 3.4 and earlier
(-std=c++1y), so it makes life slightly easier to move past it to 3.9.
Change-Id: I66fa578dd3222c62907496a888f8068ed0918c7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34819
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "append" option of the Help() scons method can be used to avoid
clobbering the built in and local option help.
This has the nice side effect of making it easier to add options in
other files since you now only need the built in AddOption provided by
scons itself, not the custom AddLocalOption version.
Change-Id: Ifa566087797d578df0c90f8f4fca70c8152fbf63
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32115
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
This code was at least a little Alpha specific, and now that Alpha is
gone it can no longer be compiled. We could either fix it up to work
with other/all ISAs or delete it, and the consensus was to delete it. It
could potentially be revived in the future by retrieving it from version
control.
Change-Id: Ied073f2b9b166951ecba3442cd762eb19bc690b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32954
Reviewed-by: Steve Reinhardt <stever@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This option was for use with the old scons based regression tests.
Those had been deleted for a while, but some other bits and pieces
related to them were still lying around, depending on this option. Now
that those have been cleaned up, this option can go away.
Change-Id: I95b41dd0a14c51e74d1e527eb40e09f49aaeaf7e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32122
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like the optparse module's add_option method, most keyword arguments
have sensible default values. We should avoid setting those explicitly
when calling AddOption, since it usually doesn't make anything clearer
and just adds more text to wade through.
Change-Id: I70e425d9f1a0da1cafcc3d7dd24bfde18c0b3f35
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32116
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It appears that scons bugs are not on tigris.org any more and are now
on github, although fortunately old bugs seem to have been ported over
and have the same numbering.
This CL updates URLs which were in comments in the gem5 source,
specifically in scons scripts, to point to the corresponding github
version.
I also checked to see if these bugs were still open, or if we could
remove our workarounds for them.
1. 2356 is still open, and has been fairly recently assigned.
2. 2611 is marked as fixed. We might be able to implement the
workaround in its last comment from August of 2019.
3. 2811 has been marked fixed, and as best I can tell the fix first
appeared in around version 3.0 of scons. If/when that is our
minimum version, we can remove the workaround in
site_scons/site_tools/default.py. That is mostly fixing an annoying
spurious rebuild by scons which does not affect correctness, so even
if we remove that workaround we shouldn't break earlier versions,
although it would be obnoxious for people that are affected by it
and best avoided.
Change-Id: I0d74820f399044c6f80148bf3022d07d7bf6f4e5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32114
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We already provide to the user the CCFLAGS_EXTRA, LDFLAGS_EXTRA
variables to pass flags to scons when compiling/linking gem5.
Those variables are not passed to the marshal object.
We add an extra pair:
MARSHAL_CCFLAGS_EXTRA, MARSHAL_LDFLAGS_EXTRA
to add flag injection capabilities to the marshal object.
The patch is also renaming base_py_env to marshal_env.
This happens for 2 reasons:
1) At the moment the marshal compilation is the only task
making use of the base python environment.
2) Consistency with the EXTRA variable names added with this patch.
I could have named them as BASE_XXFLAGS_EXTRA, but it seems too much
generic and users might be confused by that, as they might think
the BASE_XXFLAGS_EXTRA is a subset of the XXFLAGS_EXTRA so that
setting it will affect gem5 compilation as well.
Change-Id: I3e420caa897059455ff8f35462db2b38da050e93
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30016
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The defaulted-function-deleted warning triggers in generated code which
would be very tricky to address.
The c99-designator refers to using an array index to specify which
element of an array is being initialized. This makes the code more
clear and is supported by both g++ and clang++. Designated initializers
for structures are being introduced in C++20, but there is no word I
could find on arrays. This warning option seems to only exist in clang
versions 10 and up, so we can only use it on those versions.
Change-Id: I8fb858e643814638c552a49336db2672be8e43c8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29396
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This reverts commit f41abbdb5c,
"scons: Enable LTO and partial linking with gcc >= 8.1."
LTO and partial linking does not work on GCC 9.3 on Ubuntu 20.04 when
compiling gem5.fast. This error was exposed via the following command:
```
docker run -u $UID:$GID --volume $(pwd):/gem5 -w /gem5 --rm \
gcr.io/gem5-test/ubuntu-20.04_all-dependencies:latest scons \
build/MIPS/gem5.fast
```
The following error was received:
```
usr/bin/ld: cannot find lib.fo.partial.lto.o: No such file or directory
/usr/bin/ld: error: could not unlink output file
collect2: error: ld returned 1 exit status
scons: *** [build/MIPS/mem/ruby/system/lib.fo.partial] Error 1
```
Issue-on: https://gem5.atlassian.net/browse/GEM5-555https://gem5.atlassian.net/browse/GEM5-557
Change-Id: Id9e7fc81aec9f94524acc92c05aabdf96bd284cd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29272
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The bug(s) which prevented LTO and partial linking from working with gcc
have been fixed in my local version (9.3), and according to one of the
original bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
A fix was committed in gcc version 8.1.
The original code left in the SConstruct describing the problem with
versions greated than 6.0 also enabled an -flinker-output option and set
it to "rel". That option doesn't show up in the gcc 8.4 documentation
even though it was added in 6.0, but in the 9.3 documentation it
describes it and says that it defaults to "rel" when the -r (partial
linking) option is used.
This *should* mean that LTO and partial linking can be used together
with no issues after version 8.1, and at most by version 9.3. If someone
finds that that isn't true, then the range of bad versions can be
expanded.
Change-Id: Ie0529d077a0042ef55e2af995d01430d1695c031
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27131
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Python 3 uses the concepts of two different types:
text and binary strings.
Those cannot be implicilty combined (as it was happening in python2) and
in order to be used together one of them must be converted to the other
type:
* Text can be encoded into Bytes via the encode() method
* Bytes can be decoded to Text using the decode() method
By default encode/decode will assume UTF-8 format
JIRA: https://gem5.atlassian.net/browse/GEM5-345
Change-Id: I1bdf7db17b49cc109239fd5f44791769370853f8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26250
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
* dict methods dict.keys(), dict.items() and dict.values()
return "views" instead of lists
* The dict.iterkeys(), dict.iteritems() and dict.itervalues()
methods are no longer supported.
* map() and filter() return iterators.
* range() now behaves like xrange() used to behave, except it works with
values of arbitrary size. The latter no longer exists.
* zip() now returns an iterator.
Change-Id: Id480018239db88d7f5d60588c93719056de4a0c0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Not running the systemc test SConscript reduces the scons startup time
(before any file is compiled) from about 10s to 4s on my machine.
The performance investigation was done at:
https://gem5.atlassian.net/browse/GEM5-256
As before, the systemc tests are still automatically built when
they are run with:
src/systemc/tests/verify.py --update-json build/ARM -j `nproc` \
--filter-file src/systemc/tests/working.filt
Change-Id: I33b7a53c0a7d70386ab17d7bb4886c84a97a2eb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25385
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I've arbitrarily chosen to make ARM the default ISA for now, since I
think it's the best supported ISA with X86 somewhere a little behind
it. As a compromise, I change all mention of ALPHA (or even ALPHA_SE!)
in comments to be X86 instead, so it gets some attention too.
Change-Id: I1d8edc7925ca2d94f11b26e2c0b9314216e9b97d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
