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>
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).
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
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.
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.
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().
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.
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.
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).
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.
This patch bumps the supported version of gcc from 4.4 to 4.6, and
clang from 2.9 to 3.0. This enables, amongst other things, range-based
for loops, lambda expressions, etc. The STL implementation shipping
with 4.6 also has a full functional implementation of unique_ptr and
shared_ptr.
This patch encompasses several interrelated and interdependent changes
to the ISA generation step. The end goal is to reduce the size of the
generated compilation units for instruction execution and decoding so
that batch compilation can proceed with all CPUs active without
exhausting physical memory.
The ISA parser (src/arch/isa_parser.py) has been improved so that it can
accept 'split [output_type];' directives at the top level of the grammar
and 'split(output_type)' python calls within 'exec {{ ... }}' blocks.
This has the effect of "splitting" the files into smaller compilation
units. I use air-quotes around "splitting" because the files themselves
are not split, but preprocessing directives are inserted to have the same
effect.
Architecturally, the ISA parser has had some changes in how it works.
In general, it emits code sooner. It doesn't generate per-CPU files,
and instead defers to the C preprocessor to create the duplicate copies
for each CPU type. Likewise there are more files emitted and the C
preprocessor does more substitution that used to be done by the ISA parser.
Finally, the build system (SCons) needs to be able to cope with a
dynamic list of source files coming out of the ISA parser. The changes
to the SCons{cript,truct} files support this. In broad strokes, the
targets requested on the command line are hidden from SCons until all
the build dependencies are determined, otherwise it would try, realize
it can't reach the goal, and terminate in failure. Since build steps
(i.e. running the ISA parser) must be taken to determine the file list,
several new build stages have been inserted at the very start of the
build. First, the build dependencies from the ISA parser will be emitted
to arch/$ISA/generated/inc.d, which is then read by a new SCons builder
to finalize the dependencies. (Once inc.d exists, the ISA parser will not
need to be run to complete this step.) Once the dependencies are known,
the 'Environments' are made by the makeEnv() function. This function used
to be called before the build began but now happens during the build.
It is easy to see that this step is quite slow; this is a known issue
and it's important to realize that it was already slow, but there was
no obvious cause to attribute it to since nothing was displayed to the
terminal. Since new steps that used to be performed serially are now in a
potentially-parallel build phase, the pathname handling in the SCons scripts
has been tightened up to deal with chdir() race conditions. In general,
pathnames are computed earlier and more likely to be stored, passed around,
and processed as absolute paths rather than relative paths. In the end,
some of these issues had to be fixed by inserting serializing dependencies
in the build.
Minor note:
For the null ISA, we just provide a dummy inc.d so SCons is never
compelled to try to generate it. While it seems slightly wrong to have
anything in src/arch/*/generated (i.e. a non-generated 'generated' file),
it's by far the simplest solution.
This patch fixes an issue with the way the python-config path is
parsed, as it caused issues on systems where a newline ended up being
included in the path.
Compile gem5 on systems where python2 and python3 co-exists without any
changes in path. python2-config is chosen over python-config if it exists.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
