This section describes the linking related options. There are three linking strategies available which are dynamic scaffold, static scaffold and user defined. The dynamic scaffold is enabled by default and each module will register itself to the run time ‘M2RTS’ via a constructor. The static scaffold mechanism will invoke each modules ‘_init’ and ‘_finish’ function in turn via a sequence of calls from within ‘main’. Lastly the user defined strategy can be implemented by turning off the dynamic and static options via ‘-fno-scaffold-dynamic’ and ‘-fno-scaffold-static’.
In the simple test below:
$ gm2 hello.mod
the driver will add the options ‘-fscaffold-dynamic’ and ‘-fgen-module-list=-’ which generate a list of application modules and also creates the ‘main’ function with calls to ‘M2RTS’. It can be useful to add the option ‘-fsources’ which displays the source files as they are parsed and summarizes whether the source file is required for compilation or linking.
If you wish to split the above command line into a compile and link then you could use these steps:
$ gm2 -c -fscaffold-main hello.mod $ gm2 hello.o
The ‘-fscaffold-main’ informs the compiler to generate the ‘main’ function and scaffold. You can enable the environment variable ‘GCC_M2LINK_RTFLAG’ to trace the construction and destruction of the application. The values for ‘GCC_M2LINK_RTFLAG’ are shown in the table below:
value | meaning
=================
all | turn on all flags below
module | trace modules as they register themselves
hex | display the hex address of the init/fini functions
warning | show any warnings
pre | generate module list prior to dependency resolution
dep | trace module dependency resolution
post | generate module list after dependency resolution
force | generate a module list after dependency and forced
| ordering is complete
The values can be combined using a comma separated list.
One of the advantages of the dynamic scaffold is that the driver behaves in a similar way to the other front end drivers. For example consider a small project consisting of 4 definition implementation modules (‘a.def’, ‘a.mod’, ‘b.def’, ‘b.mod’, ‘c.def’, ‘c.mod’, ‘d.def’, ‘d.mod’) and a program module ‘program.mod’.
To link this project we could:
$ gm2 -g -c a.mod $ gm2 -g -c b.mod $ gm2 -g -c c.mod $ gm2 -g -c d.mod $ gm2 -g program.mod a.o b.o c.o d.o
The module initialization sequence is defined by the ISO standard to follow the import graph traversal. The initialization order is the order in which the corresponding separate modules finish the processing of their import lists.
However, if required, you can override this using ‘-fruntime-modules=a,b,c,d’ for example which forces the initialization sequence to ‘a’, ‘b’, ‘c’ and ‘d’.