40f14ff2b1f84046f00bb97c16ffdaa2bb65f696
The *vast* majority of SimObjects use the standard boilerplate version of their Params::create() method which just returns new ClassName(*this); Rather than force every class to define this method, or annoy and frustrate users who forget and then get linker errors, this change automates the default while leaving the possibility of defining a custom create() method for non-default cases. The situations this mechanism handles can be first broken down by whether the SimObject class has a constructor of the normal form, ie one that takes a const Params reference as its only parameter. If no, then no default create() implementation is defined, and one *must* be defined by the user. If yes, then a default create() implementation is defined as a weak symbol. If the user still wants to define their own create method for some reason, perhaps to add debugging info, to keep track of instances in c++, etc., then they can and it will override the weak symbol and take precedence. The way this is implemented is not straightforward. A set of classes are defined which use SFINAE which either map in the real Params type or a dummy based on whether the normal constructor exists in the SimObject class. Then those classes are used to define *a* create method. Depending on how the SFINAE works out, that will either be *the* create method on the real Params struct, or a create method on a dummy class set up to just absorb the definition and then go away. In either case the create() method is a weak symbol, but in the dummy case it doesn't/shouldn't matter. Annoyingly the compiler insists that the weak symbol be visible. While that makes total sense normally, we don't actually care what happens to the weak symbol if it's attached to the dummy class. Unfortunately that means we need to make the dummy class globally visible, although we put it in a namespace to keep it from colliding with anything useful. Change-Id: I3767a8dc8dc03665a72d5e8c294550d96466f741 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35942 Reviewed-by: Gabe Black <gabe.black@gmail.com> Reviewed-by: Richard Cooper <richard.cooper@arm.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.
Description