| Age | Commit message (Collapse) | Author |
|---|
|
The value of that variable can be computed more directly and more locally
to where it's consumed.
Change-Id: I5ca1f732a34e22d4dae2aeb6ee7fc8adebe1caa0
Reviewed-on: https://gem5-review.googlesource.com/2981
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
It seems that g++ can generally handle the -r flag for generating a
relocatable object file, but ld can't always handle the --relocatable
flag.
Change-Id: I15f32e469590a814131d4e992b392a7ad6c52b83
Reviewed-on: https://gem5-review.googlesource.com/3001
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Remove remaining SWIG support from the build infrastructure.
Change-Id: I7549cd0f952ca3a51481918eefef3a29f03af359
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2920
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.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>
|
|
Change-Id: I52e4fc9ebf2f59da57d8cf8f3e37cc79598c2f5f
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2229
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
|
|
These intermediate object files can be used to perform a hierarchical
link.
Change-Id: I27634731734eebe6531ce6b0894abdd59ffdc5c9
Reviewed-on: https://gem5-review.googlesource.com/2944
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I7ddba0cc7be559633328011c1c7e2282f509b78c
Reviewed-on: https://gem5-review.googlesource.com/2943
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
|
|
Change-Id: I71d07fc64bdb3c6c3e93e2a1fd358cc899a70678
Reviewed-on: https://gem5-review.googlesource.com/2500
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.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>
|
|
Various changes we found needed to build gem5 successfully on
FreeBSD.
Reviewed at http://reviews.gem5.org/r/3378/
Signed-off-by: Jason Lowe-Power <jason@lowepower.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).
|
|
---
SConstruct | 4 ++++
1 file changed, 4 insertions(+)
|
|
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>
|
|
Change-Id: Ied2e018a9a1b6db446edbaac871ac4efd795ec36
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Don't use Python 2.7-style with statements in the SConstruct file.
|
|
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
|
|
Allow the user to easily build gem5 with the Address Sanitizer, part
of both gcc and clang these days.
|
|
|
|
Make best use of the compiler, and enable -Wextra as well as
-Wall. There are a few issues that had to be resolved, but they are
all trivial.
|
|
This patch replaces the gzstream zlib wrapper with the iostream3
wrapper provided as part of zlib contributions. The main reason for
the switch is to avoid including LGPL in the default gem5
build. iostream3 is provided under a more permissive license:
The code is provided "as is", with the permission to use, copy,
modify, distribute and sell it for any purpose without fee.
|
|
Add functionality to generate a back trace if gem5 crashes (SIGABRT or
SIGSEGV). The current implementation uses glibc's stack traversal
support if available and stubs out the call to print_backtrace()
otherwise.
|
|
|
|
Add revision 9adf9d6e2d889a483a92136c96eb8a434d360561 of NoMali-model
from https://github.com/ARM-software/nomali-model. This library
implements the register interface of the Mali T6xx/T7xx series GPUs,
but doesn't do any rendering. It can be used to hide the effects of
software rendering.
|
|
e56c3d8 (2008) added it but 8e37348 (2010) removed its only use.
|
|
This patch updates the compiler minimum requirement to gcc 4.7 and
clang 3.1, thus allowing:
1. Explicit virtual overrides (no need for M5_ATTR_OVERRIDE)
2. Non-static data member initializers
3. Template aliases
4. Delegating constructors
This patch also enables a transition from --std=c++0x to --std=c++11.
|
|
Make scons a bit more forgiving when determining the GNU assembler version.
|
|
This changeset adds support for aarch64 in kvm. The CPU module
supports both checkpointing and online CPU model switching as long as
no devices are simulated by the host kernel. It currently has the
following limitations:
* The system register based generic timer can only be simulated by
the host kernel. Workaround: Use a memory mapped timer instead to
simulate the timer in gem5.
* Simulating devices (e.g., the generic timer) in the host kernel
requires that the host kernel also simulates the GIC.
* ID registers in the host and in gem5 must match for switching
between simulated CPUs and KVM. This is particularly important
for ID registers describing memory system capabilities (e.g.,
ASID size, physical address size).
* Switching between a virtualized CPU and a simulated CPU is
currently not supported if in-kernel device emulation is
used. This could be worked around by adding support for switching
to the gem5 (e.g., the KvmGic) side of the device models. A
simpler workaround is to avoid in-kernel device models
altogether.
|
|
The current build tests for KVM unconditionally check for xsave
support. This obviously never works on ARM since xsave is
x86-specific. This changeset refactors the build tests probing for KVM
support and moves the xsave test to an x86-specific section of
is_isa_kvm_compatible().
|
|
Allow the user to send signals such as Ctrl C to the gem5 runs. Note
that this assumes coreutils >= 8.13, which aligns with Ubuntu 12.04
and RHE6.
|
|
Work around a bug in scons that causes the param wrappers being
compiled twice. The easiest way for us to do so is to tell scons to
ignore implicit command dependencies.
|
|
We need it to determine whether we should expect KVM related parameters
exist in the cirrus graphics device.
|
|
This patch adds sorting based on the SimObject name or parameter name
for all situations where we iterate over dictionaries. This should
ensure a deterministic and consistent order across the host systems
and hopefully avoid regression results differing across python
versions.
|
|
This patch adds the ability to load in config.ini files generated from
gem5 into another instance of gem5 built without Python configuration
support. The intended use case is for configuring gem5 when it is a
library embedded in another simulation system.
A parallel config file reader is also provided purely in Python to
demonstrate the approach taken and to provided similar functionality
for as-yet-unknown use models. The Python configuration file reader
can read both .ini and .json files.
C++ configuration file reading:
A command line option has been added for scons to enable C++ configuration
file reading: --with-cxx-config
There is an example in util/cxx_config that shows C++ configuration in action.
util/cxx_config/README explains how to build the example.
Configuration is achieved by the object CxxConfigManager. It handles
reading object descriptions from a CxxConfigFileBase object which
wraps a config file reader. The wrapper class CxxIniFile is provided
which wraps an IniFile for reading .ini files. Reading .json files
from C++ would be possible with a similar wrapper and a JSON parser.
After reading object descriptions, CxxConfigManager creates
SimObjectParam-derived objects from the classes in the (generated with this
patch) directory build/ARCH/cxx_config
CxxConfigManager can then build SimObjects from those SimObjectParams (in an
order dictated by the SimObject-value parameters on other objects) and bind
ports of the produced SimObjects.
A minimal set of instantiate-replacing member functions are provided by
CxxConfigManager and few of the member functions of SimObject (such as drain)
are extended onto CxxConfigManager.
Python configuration file reading (configs/example/read_config.py):
A Python version of the reader is also supplied with a similar interface to
CxxConfigFileBase (In Python: ConfigFile) to config file readers.
The Python config file reading will handle both .ini and .json files.
The object construction strategy is slightly different in Python from the C++
reader as you need to avoid objects prematurely becoming the children of other
objects when setting parameters.
Port binding also needs to be strictly in the same port-index order as the
original instantiation.
|
|
This patch adds the Undefined Behavior Sanitizer (UBSan) for clang and
gcc >= 4.9. Due to the performance impact, the usage is guarded by a
command-line option.
|
|
Disabling tcmalloc is required for valgrind's memcheck to work properly;
this option makes it easier to create such a build.
|
|
Add the ability to build libgem5 without embedded Python or the
ability to configure with Python.
This is a prelude to a patch to allow config.ini files to be loaded
into libgem5 using only C++ which would make embedding gem5 within
other simulation systems easier.
This adds a few registration interfaces to things which cross
between Python and C++. Namely: stats dumping and SimObject resolving
|
|
This patch adds the open-source (BSD 3-clause) tool DRAMPower, commit
8d3cf4bbb10aa202d850ef5e5e3e4f53aa668fa6, to be built as a part of the
simulator. We have chosen this specific version of DRAMPower as it
provides the necessary functionality, and future updates will be
coordinated with the DRAMPower development team. The files added only
include the bits needed to build the library, thus excluding all
memory specifications, traces, and the stand-alone DRAMPower
command-line tool.
A future patch includes the DRAMPower functionality in the DRAM
controller, to enable on-line DRAM power modelling, and avoid using
post-processing of traces.
|
|
|
|
Fix a number few minor issues to please gcc 4.9.1. Removing the
'-fuse-linker-plugin' flag means no libraries are part of the LTO
process, but hopefully this is an acceptable loss, as the flag causes
issues on a lot of systems (only certain combinations of gcc, ld and
ar work).
|
|
When GNU coreutils 'timeout' is available, limit each regression
simulation to 4 hours.
|
|
We currently generate and compile one version of the ISA code per CPU
model. This is obviously wasting a lot of resources at compile
time. This changeset factors out the interface into a separate
ExecContext class, which also serves as documentation for the
interface between CPUs and the ISA code. While doing so, this
changeset also fixes up interface inconsistencies between the
different CPU models.
The main argument for using one set of ISA code per CPU model has
always been performance as this avoid indirect branches in the
generated code. However, this argument does not hold water. Booting
Linux on a simulated ARM system running in atomic mode
(opt/10.linux-boot/realview-simple-atomic) is actually 2% faster
(compiled using clang 3.4) after applying this patch. Additionally,
compilation time is decreased by 35%.
|
|
This changeset fixes three types of warnings that occur in clang 3.4
on Ubuntu 12.04:
* Certain versions of libstdc++ (primarily 4.8) use struct and class
interchangeably. This triggers a warning in clang.
* Swig has a tendency to generate code with the register class which
was deprecated in C++11. This triggers a deprecation warning in
clang.
* Swig sometimes generates Python wrapper code which returns
uninitialized values. It's unclear if this is actually a problem
(the cases might be limited to failure paths). We'll silence these
warnings for now since there is little we can do about the
generated code.
|
|
It seems gcc >4.8 does not get along well with binutils <= 2.22, and
to help users this patch adds a warning with an indication for how to
fix the issue. It might even be worth adding a Exit(-1) and stop the
build.
|
