Commit f9c01ed0 authored by Committed by ROOL
Enable rom_link target for AAsmModule components
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.
Showing with 15 additions and 3 deletions