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>
the GPUCoalescer code is used in the ruby profiler regardless of
whether or not the coalescer code has been compiled, which can
lead to link/run time errors. here we add #ifdefs to guard the
usage of GPUCoalescer code. eventually we should refactor this
code to use probe points.
After reaching consensus on the mailing list, this patch officially
makes gcc 4.8 the minimum.
A few checks in the SConstruct are cleaned up as a result. This patch
also adds "-fno-omit-frame-pointer" when using ASAN (which is part of
the gcc/clang recommended flags).
The SCons script currently assumes that .git is a proper directory
with all git meta data. This isn't the case if the working directory
was checked out using git worktrees. In such case .git is a file with
meta data telling git where the repository data is stored.
This changeset updates changes the SConstruct file to rely on git
rev-parse to get the real git directory.
Change-Id: I3d0475eabc12e868193797067a88e540a9b6e927
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Add a check in the main SConscript that installs the git pre-commit
hook in util/ if git is used.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
[andreas.sandberg@arm.com: Cleanups suggested by Steve]
Reviewed-by: Steve Reinhardt <steve.reinhardt@amd.com>
--HG--
extra : rebase_source : 4b805cdd74bc5442a65abf8a62e3e341f352c04e
The Mercurial style checker extensions are currently stored in
style.py. This is not ideal since they won't work with other version
control systems. This changeset renames style.py to hgstyle.py and
adds upgrade code to scons that automatically updates the hooks in
hgrc.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Nathanael Premillieu <nathananel.premillieu@arm.com>
Reviewed-by: Steve Reinhardt <steve.reinhardt@amd.com>
--HG--
rename : util/style.py => util/hgstyle.py
extra : rebase_source : ee8107ef245901371b368b7c2046ecdd89e3ff4c
