Difference between revisions of "Build System"
|Line 236:||Line 236:|
=== Using EXTRAS ===
Revision as of 03:59, 11 April 2011
M5's build system is based on Scons, an open source build system implemented in python. You can find more information about scons at www.scons.org. The main scons file is called SConstruct and is found in the root of the source tree. additional scons files are called SConscript and are found throughout the tree, usually near the files they're associated with.
In M5, scons build targets are of the form <build dir>/<configuration>/<target>. The <build dir> part of the target is a directory path that ends in "build". Typically this is simply "build" by itself, but you can specify a directory called "build" located somewhere else instead. The <configuration> part selects a set of preset build configuration variables values which correspond to common . The possible options are the file names in the build_opts directory, and are discussed more below. The build targets can be regression tests which are explained in more detail below, or they can be different versions of the M5 binary. The name of the binary is "m5" with an extension that specifies what version to build. Currently supported versions are m5.debug, m5.opt, m5.fast, and m5.prof.
m5.debug has optimizations turned off. This ensures that variables won't be optimized out, functions won't be unexpectedly inlined, and control flow will won't behave in surprising ways. That makes this version easier to work with in tools like gdb, but without optimizations this version is significantly slower than the others. You should choose it when using tools like gdb and valgrind and don't want any details obscured, but other wise more optimized versions are recommended.
m5.opt has optimizations turned on and debugging functionality like asserts and DPRINTFs left in. This gives a good balance between the speed of the simulation and insight into what's happening in case something goes wrong. This version is best in most circumstances.
m5.fast has optimizations turned on and debugging functionality compiled out. This pulls out all the stops performance wise, but does so at the expense of run time error checking and the ability to turn on debug output. This version is recommended if you're very confident everything is working correctly and want to get peak performance from the simulator.
m5.prof is similar to m5.fast but also includes instrumentation that allows it to be used with the gprof profiling tool. This version is not needed very often, but can be used to identify the areas of M5 that should be focused on to improve performance.
These versions are summarized in the following table.
|Binary name||Optimizations||Run time debugging support||Profiling support|
Command line options
Scons will recognize the following command line options specific to M5.
|--color||Turn on colorized output|
|--no-color||Turn off colorized output|
|--default||Override which build_opts file to use for defaults|
|--ignore-style||Disable style checking hooks|
|--update-ref||Update test reference outputs|
|--verbose||Print full tool command lines|
The following environment variables are imported from the host environment for use in scons:
|AR||Archive tool command|
|CC||C compiler command|
|CXX||C++ compiler command|
|HOME||User's home directory|
|LD_LIBRARY_PATH||Path to search for library files|
|PATH||Path to search for programs|
|PYTHONPATH||Path to search for python files|
|M5_CONFIG||Where to look for the special ".m5" directory|
|M5_DEFAULT_BINARY||The default build target which overrides the default default build/ALPHA_SE/m5.debug|
These configuration variables are used to control the way M5 is built. Some are global, affecting all configurations in a build directory, and some only affect the configuration being built. Unlike the command line options, these variables retain their value between invocations of scons.
|CC||C Compiler||CC environment variable or value determined by scons|
|CXX||C++ Compiler||CXX environment variable or value determined by scons|
|BATCH||Use batch pool for build and tests||False|
|BATCH_CMD||Batch pool submission command||qdo|
|M5_BUILD_CACHE||Cache built objects in this directory||False|
|EXTRAS||Add extra directories to the compilation|
|Variable||Description||Default||Exported as config/*.hh|
|CP_ANNOTATE||Enable critical path annotation capability||False||X|
|EFENCE||Link with Electric Fence malloc debugger||False|
|FAST_ALLOC_DEBUG||Enable fast object allocator debugging||False||X|
|FAST_ALLOC_STATS||Enable fast object allocator statistics||False||X|
|NO_FAST_ALLOC||Disable fast object allocator||False||X|
|NO_HTML||Do not create HTML files||False|
|NO_VECTOR_BOUNDS_CHECKS||Don't do bounds checks||True||X|
|PROTOCOL||Coherence protocol for Ruby||MI_example||X|
|RUBY||Build with Ruby||False|
|SS_COMPATIBLE_FP||Make floating-point results compatible with SimpleScalar||False||X|
|USE_CHECKER||Use checker for detailed CPU models||False||X|
|USE_FENV||Use <fenv.h> IEEE mode control||whether fenv.h was found on this host||X|
|USE_MYSQL||Use MySQL for stats output||whether mysql_config was found||X|
|USE_POSIX_CLOCK||Use POSIX Clocks||whether posix clocks are available on this host||X|
|USE_SSE2||Compile for SSE2 (-msse2) to get IEEE FP on x86 hosts||False|
Setting configuration variable values
The first way you set configuration variable values is through the configuration name you choose as part of the build target. This file is loaded from build_opts and contains preset values for some of these variables which configures the build as the file name suggests. For instance, using the SPARC_FS configuration will turn on full system mode with the FULL_SYSTEM variable and set the TARGET_ISA to sparc.
It is important to note that the values in the file corresponding to the configuration you picked are -default- values and are only used if no directory already exists with its own values already in place. Those files are for defining reasonable starting points to configure M5 to behave the way you want it to, and are not intended to actively configure a particular build.
If you want to change a value after your build and configuration directory is already created, or if you want to override a value as it's created, you can specify the new values on the command line. The syntax is similar to setting environment variables at a shell prompt, but these go after the scons command. For example, to turn on RUBY support for an existing ALPHA_FS build, you could use the following command.
scons RUBY=True build/ALPHA_FS/m5.opt
It's often a good idea to add --help to the scons command line which will print out all of the configuration variables and what their values are. This way you can make sure everything is set up like you want, and that you don't have any typos in any variable names. If everything is as you expect, you can remove --help to actually start the build.
Adding files to the build
Files are added to the build by declaring them inside SConscript files as instances of certain python classes. The build system knows how to handle those files based on what particular class was used. For instance, to add a C++ source file foo.cc to the build, you could add the following line to the SConscript in the same directory as foo.cc:
The build system finds and processes SConscript files automatically, so you can create one near the files your adding or extend one that's already there. The following table shows what types of source files there are and what they're for.
|Source file type||Description||Parameters|
|PySource||Add a python source file to the named package||package||The name of the package|
|source||The name of the python source file|
|SimObject||Add a SimObject python file as a python source object and add it to a list of sim object modules||source||The relative path to the python file defining the SimObject.|
|Source||Add a c/c++ source file to the build||source||Relative path to source file|
|Werror||Whether to compile with -Werror. Defaults to True.|
|swig||Whether to use flags suitable for a swig wrapper C++ file. Defaults to False.|
|bin_only||Whether this file should only be compiled into the main gem5 binary. Defaults to False. If set, this implies skip_lib.|
|skip_lib||Whether this file should be excluded from the library version of gem5. Defaults to False.|
|SwigSource||Add a swig file to the build||package||Package for the python version of the source.|
|source||Relative path to the swig input file.|
|UnitTest||Add a unit test to the build||sources||A list or tuple of relative paths to the source files for the unit test.|
A similar mechanism is used to define trace flags. These look very similar but don't actually refer to a file. A compound trace flag is a flag which controls a group of normal trace flags.
|Trace flag type||Description||Parameters|
|TraceFlag||Add an individual trace flag to the build.||name||The name of the new trace flag.|
|desc||A description for this flag. This is optional but recommended.|
|CompoundFlag||Add a compound trace flag to the build.||name||The name of the new compound trace flag.|
|flags||A list or tuple of the names of trace flags which this new compound trace flag will control.|
|desc||A description for this flag. This is optional but recommended.|
The EXTRAS scons variable can be used to build additional directories of source files into gem5 by setting it to a colon delimited list of paths to these additional directories. EXTRAS is a handy way to build on top of the gem5 code base without mixing your new source with the upstream source. You can then manage your new body of code however you need to independently from the main code base.