40deabcc48
To limit the number of license slots used by SCons when building fast model components, the fastmodel SConscript set up a group of nodes which are attached to each simgen run using the SCons SideEffect method using one of the library files it generates. To create each unique node, the SCons Value() method was used, passing it the counter for the loop. In at least version 4 of SCons, what this ended up doing was setting that library file as a source for each of the Value() nodes it corresponds to. That doesn't *seem* like a problem, but then when creating config include files, files which expose SCons configuration values to C++, they also create Value() nodes using the value of the config variable. In cases where that variable is boolean, the value might be 0 or 1. The result was that the config header depended on Value(0) (for instance), and then Value(0) depended on a collection of static library files. When scons tried to determine whether the config file was up to date, it tried to check if if its sources had changed. It would check Value(0), and then Value(0) would try to compute a checksum for its own source. To do that, it seems to assume that the value can be interpreted as a string and tries to decode it as utf8. Since the library is a binary file, that would fail and break the build with a cryptic message from within the guts of SCons. To address this, this change replaces the loop index with a call to object(). Each instance created in that way will be different from every other, and there will be no way (purposefully or otherwise) to create a collision with it when creating Value() nodes for some other purpose. Change-Id: I56bc842ae66b8cb36d3dcbc25796b708254d6982 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38617 Reviewed-by: Yu-hsin Wang <yuhsingw@google.com> Reviewed-by: Ahbong Chang <cwahbong@google.com> Maintainer: Gabe Black <gabe.black@gmail.com> Tested-by: kokoro <noreply+kokoro@google.com>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.