The workspace setup script has a default set of make-variables (CC, CFLAGS, etc.), which are setup in the compiler.mk and [simics]/config/config.mk files. If you need to change any of the variables in config.mk, you may override them in config-user.mk. The compiler.mk may be edited by the user.
The makefile with the actual build rules for all modules is [simics]/config/module.mk. This file is included at the end of each module Makefile. To override rules or variables in this module.mk, add a module-user.mk file in the workspace, similar to the config-user.mk file described above.
The default set of variables assumes that you will be using GCC. If you want to use a different compiler, you need to change the CC variable in compiler.mk. The flags for the compiler are setup in [simics]/config/config.mk.
If your compiler is not supported by config.mk, please report to Virtutech.
In order to make the build environment in Simics recognize a module as a build target, there must be a makefile called Makefile in its source directory.
A module makefile must set up a number of make variables and then include the generic makefile for Simics modules. The following is an example of a module's Makefile, for a module written in C:
MODULE_CLASSES=FAS366U SRC_FILES=esp.c MODULE_CFLAGS=-DFAS SIMICS_API = 3.0 include $(MODULE_MAKEFILE)
The user can also add new rules to the makefile, either before or after the inclusion of the generic $(MODULE_MAKEFILE). This is usually not needed.
The following variables can be used in the module's makefile (i.e. [workspace]/modules/<module>/Makefile). They should be considered read-only, i.e. they should not be changed.
There are a number of defines that are set depending on the host that the module is being compiled on. They are usually not needed, but useful in some special cases. Examples: HOST_64_BIT, HOST_32_BIT, HOST_BIG_ENDIAN, and HOST_LITTLE_ENDIAN. There are also defines specifying the host architecture and host operating system. All these defines are set in the Simics include file global.h.
It is possible to set a user defined version number (or string) in loadable modules. This is done by setting the USER_VERSION define in MODULE_CFLAGS in the module's Makefile. The version number will be printed by the list-modules and list-failed-modules commands.
When Simics starts, it will check all modules for their supported architecture and word size. Only modules that match the running Simics binary will be available for loading into Simics. While scanning the modules, Simics will also check what classes the module will register when it is loaded. This way modules can be loaded automatically when classes they define are used in a configuration.
If a module does not match the current Simics, it will be added to the list of failed modules. This list can be displayed with list-failed-modules, that takes an optional parameter -v for more verbose output.
simics> list-failed-modules Current module version number: 1050 Lowest version number supported: 1050 MODULE DUP VERSION USR_VERS LINK --------------------------------------------- 8042 1040 image 1040 spitfire-mmu.so X
The columns after the module name (or file name in the case of a link error) indicate different kinds of errors. An X in the DUP column means that this module could not be loaded because this module has the same name as another module found in the Simics module search path, and that this one was overridden. An X in the VERSION column means that the module was created for another, non-compatible, version of Simics. LINK means that this module cannot be loaded into Simics because of unresolved symbols. Use list-failed-modules -v to see the actual error message from the run-time module loader.