Deprecate MakeCPIO in favour of inlining binaries directly into elf files or into their final memory locations

[kent-mcleod]

The MakeCPIO function takes a list of files generates a archive.o binary containing an embedded cpio archive in its own section _archive_cpio with symbols _cpio_archive and _cpio_archive_end. This is used for embedding binaries in at least the following loaders:

• the elfloader uses it to store the kernel.elf and roottask binaries and also optionally some hashes of the included files.
• the capdl-loader-app uses it to store all the user binaries that it will load when initializing a system,
• the sel4test-driver app uses it to store any test process images it loads,
• the sel4benchapp application uses it to hold all benchmark process images it loads.
• the camkes vm project's fileserver uses it to hold kernel and rootfs images.

Problem: All current usages would benefit from being able to have the embedded binaries aligned to some page boundary. This would make copying faster as addresses are aligned better, but also for ELF files, it'd make it possible to directly map read-only segments from the original memory location. CPIO archives don't align their contents and so these embedded cpio archives always require unpacking the contents to a different memory location.

Proposal: Instead of a cpio archive ebedded in an object file, it'd be simpler to directly embed the internal file objects into the object file and for symbols to be declared for the start and end positions of the file.

This would remove the CPIO archive step in the embedding and allow images to be loaded at specific aligned addresses.

All that's required is for these projects to just move off of using the MakeCPIO utility and directly embed the files that they need at their compilation stage in their own CMake project files.

[Indanz]

I always thought the use of CPIO was a bit weird and unnecessarily complex for what's actually needed, but I assumed there originally was a reason to use CPIO.

CPIO is good for dynamic systems that don't know beforehand what files they need and actually need a filesystem of sorts. But then embedding the archive into an .o file seems to defeat the whole purpose.