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.

In addition to this, change a few modules to C type in ModuleDB.

These components have pending merge requests that mean they are likely to move to use the CModule shared makefile in the near future, which will require the use of their rom_link rule. However, due to the change to AAsmModule above, we can change their type now in anticipation.

I'm not going further and change all ASM components en masse, because not all of them will yet have been converted to use AAsmModule. This is also the reason for not making the change in srcbuild itself.