seL4
Add support for split program images
There are cases where it would be useful to be able specify the program image separately from the symbols that will be used to manipulate it.
https://github.com/seL4/rust-sel4/pull/167 adds support for resettable protection domains. The best way that I've come up with to achieve this requires manipulating the program image after linking. Specifically, a new program image is created from the original, and the result is an ELF file with only program headers, and no section headers. The symbol and debugging information in the original ELF file still apply to the final program image. So, we are left with one ELF file specifying the program image, and one ELF file with symbol and debugging information.
This PR adds support for the optional path_for_symbols attribute on the <program_image> element, which allows for such a split program image.
I've updated the PR. I've also moved code around to minimize the diff to make it easier to review. If it is going to be accepted, I'll reorganize the code again in an additional to make it more natural to read linearly.
seL4/rust-sel4#167 adds support for resettable protection domains. The best way that I've come up with to achieve this requires manipulating the program image after linking.
If you copied the data section to a read-only area of the same size after linking, and have the program use that to init its data section at startup, you ended up doing the same thing I did to implement restarting.
It's by far the cleanest solution, because it makes restarting a trivial operation. The alternative would be to basically reload (part of) the program when restarting, which has much higher complexity. If Microkit wants to have restartability support, it probably wants to do the same thing.
Specifically, a new program image is created from the original, and the result is an ELF file with only program headers, and no section headers. The symbol and debugging information in the original ELF file still apply to the final program image. So, we are left with one ELF file specifying the program image, and one ELF file with symbol and debugging information.
This isn't strictly needed to achieve your goal, but if you're modifying the binary anyway, you can as well strip it.
This PR adds support for the optional
path_for_symbolsattribute on the<program_image>element, which allows for such a split program image.
This seems useful for supporting more aggressively stripped binaries in general.
If you copied the data section to a read-only area of the same size after linking, and have the program use that to init its data section at startup, you ended up doing the same thing I did to implement restarting.
It's by far the cleanest solution, because it makes restarting a trivial operation. The alternative would be to basically reload (part of) the program when restarting, which has much higher complexity. If Microkit wants to have restartability support, it probably wants to do the same thing.
Yes, this is exactly what I did, and it did indeed turn out to work quite well.
This isn't strictly needed to achieve your goal, but if you're modifying the binary anyway, you can as well strip it.
Do you mean that it’s not necessary to end up with an ELF file with only program headers, no section headers? That’s true - ending up with an ELF file like this isn’t a goal of the ELF modification tool, but I’ve found that the simplest implementation of such a tool results in an ELF file like this.
Do you know of some linker script magic to make this not this case?
https://github.com/seL4/rust-sel4/pull/167