GitLab

The ModuleDB classifies modules as being of type either `ASM` or `C`. The
primary consumer of this information is `srcbuild`. The difference between
them, as far as `srcbuild` is concerned, is only that in the `install_rom`
phase, it builds the `rom_link` phony target in `C` components' makefiles,
instead of the `install_rom` phony target.

These phony targets differ slightly in requirements: `install_rom` uses
`INSTDIR` where `rom_link` uses `LINKDIR`, but more significantly, `rom_link`
is passed parameter `ADDRESS` to state where in the ROM the module resides.
This addesss is not known at the time the `rom` phony target is made, so `C`
components only produce a partially-linked binary at that stage, where `ASM`
components have already produced a complete binary. (The reason for this
difference is that while hand-written assembly modules use position-
independent code, the output of the Norcroft compiler normally relies on
run-time code modification to relocate absolute addresses - something that is
not possible when running from ROM.)

There are implementations of the `install_rom` and `rom_link` rules in the
`AAsmModule` and `CModule` shared makefiles respectively, so `AAsmModule` is
currently only used for `ASM` components and `CModule` is only used for `C`
components. However, occasionally we have reason to change a component from
using `AAsmModule` to `CModule`, usually for reasons unrelated to the use of
absolute address relocations, because `CModule` is more flexible than
`AAsmModule` in various other ways.

This poses a problem for keeping `BuildSys` in step with the component in
question, because whenever we change the shared makefile type in the
component's makefile, we have to update the `ModuleDB` in lock step.

The solution presented here is to ensure that at least one shared makefile
supports both phony targets, so any component using it no longer cares how it
is recorded in the `ModuleDB`. Adding `install_rom` to `CModule` was rejected,
on the grounds that it would be too easy to accidentally build a ROM using it
where the necessary relocations had been skipped at ROM link time. However,
there are no drawbacks to adding `rom_link` to AAsmModule, because linking
an object that has no relocations at any base address will always result in
an identical binary that is safe to execute.

Though the module itself requires no relocations, the symbols file
traditionally output by `CModule` does contain absolute addresses which are
useful for debugging, so a new link command is executed during `AAsmModule`'s
`rom_link` rule in order to ensure this is kept up-to-date, even though the
binary could otherwise have been re-used from the one generated in the `rom`
rule.