This header file defines everything that is visible
externally to the RTS. It includes Stg.h and everything
in the rts subdirectory.
The canonical definition of certain structures are in C header files.
For example, the layout of closures and info tables are defined in the
headers Closures.h and
InfoTables.h respectivesly. How do we get the information about the
layout of these structures to the parts of the system that are not
written in C, such as the compiler itself, or the C-- code in the RTS?
Our solution is the Haskell program in utils/deriveConstants/DeriveConstants.hs.
It determines the sizes and fields offsets from the C header files by invoking the C compiler for the target platform, and then looking at the resulting object file (we can't run the code generated by the target C compiler, because this is the host platform).
The DeriveConstants program generates a few header files, notably includes/dist-derivedconstants/header/DerivedConstants.h, which contains C #defines for each of the derived constants; this file is used by C-- code in the RTS. It also generates a few files of Haskell code which are included into GHC itself, in the DynFlags module.
Used when compiling via C
These header files are #included into the .hc file
generated by GHC when it compiles Haskell code to C. They are also
#included by Rts.h, so the definitions from these files are shared
by the RTS code.
These days the amount of stuff included this way is kept to a minimum.
In particular, there are no function prototypes: all calls to C
functions from .hc files are given types at the call site.