The flags may be passed as:
scons CCFLAGS_EXTRA='-Wno-error -pedantic' \
LDFLAGS_EXTRA='-g -g' build/<arch>/gem5.opt
The initial motivation for this commit is to help disable warning that
have become errors while bisecting.
scons orders the flags by Append call order, and ideally these flags
should be added last to override the others, since the last GCC flags
take precedence. However I haven't found a simple way to put them at
the very end.
Change-Id: Ida24dfb9604d88b99f113392ab5e47d578ba7259
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19048
Reviewed-by: Juha Jäykkä <juha.jaykka@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add NUMBER_BITS_PER_SET environment variable to control
the size of the bitmask in Set.hh (default=64).
Necessary for configs which require >64 instances of a given
machine type. This can be set in the build_opts file, e.g.
by adding the following line:
NUMBER_BITS_PER_SET = <number>
Change-Id: I314a3cadca8ce975fcf4a60d9022494751688e88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18968
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
isdir isn't a nice way to check if an FS.Base is a File or a Dir as was
initially assumed, it literally checks if a path can be stat-ed and is
reported as a directory by stat. This means that if a directory is
going to be created as part of the build, the result of that test will
change depending on whether that part of the build has happened
successfully before.
A better check which behaves as originally intended is to check whether
the Node is an instance of the SCons.Node.FS.Dir class.
Change-Id: Id041917d50b768a8205769c0a05320f92b09993c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17128
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Add a sticky variable (PYTHON_CONFIG) to select which python-config
version to use. This can, for example, be used to build with Python 3
or with Python 2.7 in a custom location.
Change-Id: I1f4c00d66f85a9c99f50fe4d746b69dd82b60b4b
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/16003
Reviewed-by: Gabe Black <gabeblack@google.com>
When linking in a dynamic library which is in the gem5 build directory,
it's useful to set RPATH so that you don't have to set LD_LIBRARY_PATH
when you run gem5 so that the dynamic linker can find it.
Since it's tricky and not entirely obvious how to set up those paths
correctly, this change adds a small convenience function which does
that for you. It also handles situations where the same dynamic
library may be linked into different binaries in different directories
which each need a different relative RPATH. It does that by letting the
environment for each binary set a construction variable which says
how to get from that particular binary back to the build directory.
This helper method then sets RPATH to start at $ORIGIN (the binary),
to follow that relative path to the variant build directory, and then
the per-library but not per-binary path to the library's directory.
This change also adds the -z origin linker flag which makes the linker
handle $ORIGIN properly.
Change-Id: I45f4d72cd14396a73e0b963cea6a39d9bfb7f984
Reviewed-on: https://gem5-review.googlesource.com/c/16566
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Recent MacOS versions are distributed with python 2.7.
This version of python is sufficient to compile and run gem5.
This patch allows to use the default python instead of the version provided
by third-party tools (e.g., brew)
The default MacOS LLDB debugger is linked against the default python
installation, which conflicts with Python framework provided by third-party
package systems.
This patch removes the need of gem5 to have multiple python installations
on MacOS, if not explicitly installed.
Change-Id: I98f24804149cb2e04ca432c66d2f57e0296af7b2
Reviewed-on: https://gem5-review.googlesource.com/c/15475
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This option can significantly speedup link time on Linux systems, which is
the main bottleneck to rebuild after small changes.
Change-Id: I3b0bdd61f7dcef0d73629c8ee2ee98091953fec3
Reviewed-on: https://gem5-review.googlesource.com/c/14075
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
GNU as 2.31.1 checks if the input and output files are the same:
Assembler messages:
Fatal error: The input and output files must be distinct
The check already does not work for llvm-as which has a different
output format.
Since it is too hard to maintain the check correctly for all possible
assemblers, it is better to just remove it completely.
Change-Id: I38a993ab83ca83d4a2f5e77820d2ca903f70c6ac
Reviewed-on: https://gem5-review.googlesource.com/12403
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Sometimes it's easier to debug gem5 built with ASan enabled. This CL fixes
some build error when using --with-asan.
Bug: None
Test: ./scripts/build_gem5 --with-asan --with-ubsan build/ARM/gem5.debug
Change-Id: Iaaaaebc3f25749e11f97bf454ddd0153b3de56e7
Reviewed-on: https://gem5-review.googlesource.com/12511
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Valgrind can get confused when switching stacks between different
Fibers. If valgrind (and its headers) are available, this change adds
calls to some hooks so valgrind knows where the new stacks are and
doesn't report a bunch of false positives.
Change-Id: I00aefe60372be6de7371dec29427d7182dbee7b6
Reviewed-on: https://gem5-review.googlesource.com/12227
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
One of the most common errors during the installation of gem5 is the one
related to the failure of the check of the Python2.7 headers in the
SConstruct file. In some cases the headers are correctly installed, but a
wrong selection of the C compiler can make this check fail. This commit
wants to add some useful information this error message.
Change-Id: I0d087ad01c6e4cca3559f23070c37b5c13600962
Reviewed-on: https://gem5-review.googlesource.com/11389
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Starting with version 3, scons imposes using the print function instead
of the print statement in code it processes. To get things building
again, this change moves all python code within gem5 to use the
function version. Another change by another author separately made this
same change to the site_tools and site_init.py files.
Change-Id: I2de7dc3b1be756baad6f60574c47c8b7e80ea3b0
Reviewed-on: https://gem5-review.googlesource.com/8761
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Change backtrace implementation testing code not to have NULL pointer.
SCons fails to find backtrace implementation even if it exists.
The implementation testing code contains NULL pointers as a backtrace
buffer argument. Some compilers check the buffer is NULL pointed
or not, and generate a compilation error.
Change-Id: Icc5bc9a887b7a6bbc804b5b8a5a35a935c78a922
Reviewed-on: https://gem5-review.googlesource.com/7681
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make site_init.py manage sys.path, and the "default" tool set
PYTHONPATH on any environment that's created. The paths to add are
tracked in a common gem5_python_paths.py.
Change-Id: I3387d4394d47a2f9c83322644cfd05909c6890fa
Reviewed-on: https://gem5-review.googlesource.com/5564
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This imports various environment variables into the scons environment,
and sets some general properties on it. These are basically just copied
directly from the SConstruct and have the same behavior here.
gem5_tool_list will be used later on to add scons "tools" which should
be automatically added to new Environment objects.
Change-Id: Ib255955090c7b1e1cb80c703c18a9c867fcf1c9e
Reviewed-on: https://gem5-review.googlesource.com/5562
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
In an effort to shrink and modularize the main scons files, this
change pulls the scons and python version checking code out of the
main file and into site_init.py which runs before the SConstruct
starts. This will be a place to put really generic code which has to
do with the very fundemental aspects of getting scons to work. Other
checks, like checks for particular tools or particular versions of
tools, will happen in other more specialized files.
Change-Id: Icd00ecadbe1141aef4dbadcf42d6ddef1f3a701f
Reviewed-on: https://gem5-review.googlesource.com/5561
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Originally it was possible to use a Bitmap writer class for dumping a
framebuffer snapshot in a .bmp file. This patch enables you to choose
another format. In particular it implements the writing of PNG Images
using libpng library. The latter has to be already installed in your
machine, otherwise gem5 will default to the Bitmap format. This
configurable writer has been introduced in the VNC frame dumping mechanism,
which is storing changed frame buffers from the VNC server
Change-Id: Id7e5763c82235f1ce90381c8486b85a7cce734ce
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5181
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Generating dependency/build product information in the isa parser breaks scons
idea of how a build is supposed to work. Arm twisting it into working forced
a lot of false dependencies which slowed down the build.
Change-Id: Iadee8c930fd7c80136d200d69870df7672a6b3ca
Reviewed-on: https://gem5-review.googlesource.com/5081
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
gcc has had a lot of problems with incremental linking and partial linking
at the same time. Basically, the partial link assumes that it's the only
link that's going to happen, and it converts weak external symbols into
regular external symbols. Then when the real final link happens, those
symbols are duplicated and the link fails.
Versions of gcc 6 and greater add an option called -flinker-output which
lets you tell the linker to do an incremental link. Unfortunately, other
bugs make that fail, and so gcc 6 doesn't work either. Hopefully version
7 works better.
A --force-lto option was added so that, when only one of lto and partial
linking is available, you can switch from having partial linking to having
lto.
Change-Id: I5e293f5cfb07a14343dc74030d99cb161fb8bbbe
Reviewed-on: https://gem5-review.googlesource.com/3680
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The object is called EtherTap (as opposed to EtherTapStub, what the former
EtherTap was renamed to), and its existance is gated on the linux/if_tun.h
header file existing. That's probably overly strict, but it will hopefully
be minimally likely to break the build for other systems.
Change-Id: Ie03507fadf0d843a4d4d52f283c44a416c6f2a74
Reviewed-on: https://gem5-review.googlesource.com/3646
Reviewed-by: Nathan Binkert <nate@binkert.org>
Maintainer: Nathan Binkert <nate@binkert.org>
The SConstruct currently expects all explicit targets to be under a
variant directory like ARM or X86 which tells it what settings to use,
etc. There are things which scons knows how to build however, which do not
live under a variant directory, specifically everything under ext.
This change makes scons not look for a variant directory when it
encounters a target which is built by something in ext. This enables
things like explicitly building the systemc libraries, for example.
Change-Id: I8982a96fe49e3cb970ec78e11cea08703990c686
Reviewed-on: https://gem5-review.googlesource.com/3460
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Christian Menard <christian.menard@tu-dresden.de>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Factor out the ISA ness of the switching header generating function. Also
turn it into a SCons builder which builds a single header, and a wrapping
method which uses the builder on a group of header files which all target
the same subdirectory.
Change-Id: I87705f97b6ebd9baebd4ebcfea19cc1218a64ad0
Reviewed-on: https://gem5-review.googlesource.com/2983
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Use the PyBind11 wrapping infrastructure instead of SWIG to generate
wrappers for functionality that needs to be exported to Python. This
has several benefits:
* PyBind11 can be redistributed with gem5, which means that we have
full control of the version used. This avoid a large number of
hard-to-debug SWIG issues we have seen in the past.
* PyBind11 doesn't rely on a custom C++ parser, instead it relies on
wrappers being explicitly declared in C++. The leads to slightly
more boiler-plate code in manually created wrappers, but doesn't
doesn't increase the overall code size. A big benefit is that this
avoids strange compilation errors when SWIG doesn't understand
modern language features.
* Unlike SWIG, there is no risk that the wrapper code incorporates
incorrect type casts (this has happened on numerous occasions in
the past) since these will result in compile-time errors.
As a part of this change, the mechanism to define exported methods has
been redesigned slightly. New methods can be exported either by
declaring them in the SimObject declaration and decorating them with
the cxxMethod decorator or by adding an instance of
PyBindMethod/PyBindProperty to the cxx_exports class variable. The
decorator has the added benefit of making it possible to add a
docstring and naming the method's parameters.
The new wrappers have the following known issues:
* Global events can't be memory managed correctly. This was the
case in SWIG as well.
Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2231
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The ext directories with SConscripts in them are easy to find
automatically. Avoid boilerplate listing them out and SConscript()ing
them manually.
Change-Id: Ib723882aebc00e639eb8ec44904bb05ffa2c6b55
Reviewed-on: https://gem5-review.googlesource.com/2942
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Due to the way SCons caches some file system state internally, it
sometimes "remembers" that a file or directory didn't exist at some
point. The git hook installation script sometimes needs to create a
hooks directory in the repository. Due to the cached state of the
hooks directory, the build system tries to create it twice. The second
mkdir operation leads to an error since the directory already exists.
Fix this issue by clearing the cached state of the hooks directory
after creating it.
Change-Id: I3f67f75c06ef928b439a0742f7619b7e92ed093b
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2660
Reviewed-by: Gabe Black <gabeblack@google.com>
When naively computing the relative path between the git hooks directory and a
hook we want to install, that will generally start with a few ".." path
components to work back out of the .git directory into the working directory.'
If the hooks directory is actually a symlink, then following ".." directory
entries won't get us back to where we came from, they'll take us to the actual
parent directory of hooks. The relative path we computed would then try to go
forward from this other directory using a path that would have worked in the
working directory, hopefully going somewhere that doesn't exist, but
potentially going to a totally unrelated file with the same relative path.
To avoid this problem, we should expand any symlinks in both the hooks
directory path, and the path to the hook script. That way, any ".." components
will go where we'd expect them to, and the relative path will actually go from
hooks to the script we expect.
Change-Id: I64d51bc817351f89b1d60eceaf450cc0a4553415
Reviewed-on: https://gem5-review.googlesource.com/2542
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
If the hooks directory is a symlink, then there are at least two possible
scenarios to consider when installing a hook which is itself a symlink. The
first is that hooks is a relative symlink, and so is likely intended to stay
in place relative to .git and the git working directory. In that case, it's ok
for the symlinks inside of hooks to be relative to the working directory too,
since they should also stay in place relatively speaking.
The second situation is that the symlink is absolute. In that case, moving the
git working directory will move the hook relative to the hook directory, and
any relative symlink will become broken. In that case, the hook symlink needs
to be absolute.
The same logic likely applies to the .git directory itself, although I haven't
run into a situation in practice where the .git directory is actually a
symlink.
Change-Id: I047aa198094dd0fd5a841417d93b211ece02783f
Reviewed-on: https://gem5-review.googlesource.com/2541
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
When installing a git hook, it's possible for the hook to not "exist" if it's
actually a symlink which points to a file that doesn't exist. Trying to create
a new symlink in its place without first removing the old one causes a build
failure in these cases.
If the hook doesn't "exist" but is still a link, that means it's actually a
broken link and should be deleted by the hook installation function before any
new symlink is created.
Change-Id: I59aa51feb5bd74ca33e51e89cde2ceabeb41bd76
Reviewed-on: https://gem5-review.googlesource.com/2540
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Gerrit requires that all commit messages have a Change-Id tag. This
tag is added automatically by a commit message hook in Git. Include
the default Gerrit commit message hook and add it automatically using
scons to make life easier for everyone.
Change-Id: I1270fbaaadf6ed151bddf14521a38e0c1a02d131
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2166
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
