Fixed the issue that did not allow building TLM.
Build commands:
```bash
scons build/ARM/gem5.opt
scons setconfig build/ARM USE_SYSTEMC=n
scons --with-cxx-config --without-python --without-tcmalloc build/ARM/libgem5_opt.so
cd util/tlm
scons
```
Following this README, I tested it successfully with the simple examples:
https://gem5.googlesource.com/public/gem5/+/master/util/tlm/README
GitHub Issue: #591
Change-Id: If07fae2eb20ad62627e733573f61bc42d594f970
---------
Co-authored-by: Ivana Mitrovic <ivanamit91@gmail.com>
This adds a new scons flag --no-duplicate-sources to build without
linking source files to the build directory.
I find this very helpful when using CLion, since I can now generate a
compilation database using
`bear scons build/ALL/gem5.debug --no-duplicate-sources` and CLion will
now correctly semantically analyze all the files inside src/.
It also ensures that clicking on a build warning/error now opens the
real source file rather than a symlink.
This is not enabled by default since it's possible that certain use
cases are not working correctly, but the basic testing I've done so
far appears to work just fine.
It appears that with this change the `<root>/src` directory is no longer
added to `PYTHONPATH` when running `tests/main.py`, so this change
depends on https://gem5-review.git.corp.google.com/c/public/gem5/+/68757
Change-Id: Iddc9bf9c8211e68e5432c0a07f5c95f427c1ca16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
These are no longer split out and shared in the root build/ directory.
This does result in a small amount of overhead from building redundant
copies of these files, although the overhead is not significant. When
building 7 different variants of gem5, all the ISAs and NULL, the
difference on my machine was:
Before:
real 41m25.372s
user 914m22.266s
sys 41m51.816s
After:
real 42m38.074s
user 921m36.852s
sys 43m2.949s
This is about a 2-3% difference, which is a worse than typical case,
since the overhead scales with the number of variants being built.
The benefit of pulling ext/ into the variant directory is that there can
now be a single config which applies to all files used to build gem5,
and that config is represented by the variant of gem5 being built.
Change-Id: I6f0db97c63a7f3e252e7e351aa862340978e701b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56750
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This has two purposes. First, SCons assumes that once you call
Configure, you won't set up the environment the Configure is based on
until after you get the environment back from it again with
conf.Finish(). We get away with this when the cache mode for config
tests is not "force", since Configure just reuses the environment we
pass in, and any changes we make are immediately communicated between
the two.
If the cache mode *is* "force" though, SCons modifies the decider so
that everything the conf environment goes to build looks like it's out
of date. It does that by cloning the original environment, and then
using that clone to do its tests. That causes a problem because we have
a long lived "conf" object and make further changes to main, and since
the two environments are now separate the one in conf doesn't see those
updates.
Second, and more subtly, we export our "main" and "env" environments so
that other SConsopts and SConscript files can use them and define things
in them. The way Configure is designed, if the config caching mode is
"force", then it will create a new environment, and then that
environment will replace what the, for instance, "main" variable points
to when "main = conf.Finish()" is executed.
Unfortunately, if we've already Export()-ed main, we've exported what
the "main" variable pointed to at that time. Our view of "main" will
track with the value that conf.Finish() returned, but since that
construction environment is mearly derived from the main we Exported and
not actually the same thing, they have diverged at that point and will
behave independently.
To solve both of these problems, this change modifies the
gem5_scons.Configure() method so that it's a context manager instead of
a regular function. As before, it will call Configure for us and create
a configuration context, which it will yield as the "with" value. When
the context exits, all the variables in the context Finish() returns
will be shoved back into the original context with Replace(). This isn't
perfect since variables which were deleted in the environment (probably
very rare in practice) will not exist and so will not overwrite the
still existent variable in the original dict.
This has several advantages. The environment never splits into two
copies which continue on independently. It makes the lifetime of a
configuration context short, which is good because behavior during that
time is tricky and unintuitive. It also makes the scope of the context
very clear, so that you won't miss the fact that you're in a special
setting and need to pay attention to what environment you're modifying.
Also, this keeps the conceptual overhead of configuration localized to
where the configuration is happening. In parts of the SConscripts which
are not doing anything with conf, etc, they don't have to modify their
behavior since no configuration context is active.
This change is based on this change from Hanhwi Jang who identified this
problem and proposed an initial solution:
https://gem5-review.googlesource.com/c/public/gem5/+/44265
Change-Id: Iae0a292d6b375c5da98619f31392ca1de6216fcd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44389
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Hanhwi Jang <jang.hanhwi@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This is in the Accellera version of systemc, used when gem5 is built
into systemc as a black box. std::gets was depdecated in c++11, and
removed entirely in c++14. Since gem5 has moved to c++14, this can't be
brought in with "using" in that header. More recent versions of systemc
from Accellera may have this fixed, and it's pretty bad practice to have
a universal header file squash unrelated namespaces like that in the
first place.
Rather tha update all of this copy of systemc, this change just makes
the smallest adjustment possible to get things to work again.
Change-Id: I8a95665d4b5d49ffc014097714cf2e602bf9b937
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@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>
The existing scripts were including pthread code and QT code at the same
time, and also insisting on an having a set of architecture specific
source files for whatever the current architecture is.
This change selects using either QT or pthreads based on the host
architecture, distributes accumulating source files, list source files
explicitly (to avoid including redundant coroutine libraries) and makes
scons insist on an architecture specific QT implementation only if QT is
being used. It also defines a preprocessor symbol which tells some headers
whether or not pthreads are being used, and also clones the scons
environment to avoid leaking flags into the main environment used to
compile gem5 itself.
If the host architecture isn't supported by systemc, a warning will be
printed, and the various build products and SConscript files will be
skipped over.
Change-Id: I1a40123a11e49e02922a054f093246cf197087bf
Reviewed-on: https://gem5-review.googlesource.com/3461
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Reviewed-by: Christian Menard <christian.menard@tu-dresden.de>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
In the past it happened several times that some changes in gem5 broke the
SystemC coupling. Recently Accelera has changed the licence for SystemC
from their own licence to Apache2.0, which is compatible with gem5.
However, SystemC usually relies on the Boost library, but I was able to
exchange the boost calls by c++11 alternatives. The recent SystemC version
is placed into /ext and is integrated into gem5's build system. The goal is
to integrate some SystemC tests for the CI in some following patches.
Change-Id: I4b66ec806b5e3cffc1d7c85d3735ff4fa5b31fd0
Reviewed-on: https://gem5-review.googlesource.com/2240
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
