Closed PandaZ3D closed 7 months ago
According to #8 , I am inclined to believe it does have to do with alignment as described above.
LGTM, modulo that we talked about how all this load_elf stuff in userspace will be replaced soon with the dynamic linker version
ELF executables now load and run without using the workaround described above thanks to the changes from #153. The implementation is inspired by the way the dynamic linker runtime loads libraries: src/runtime/dynlink/src/library/load.rs
This PR implements the ELF loading part of the bootstrap phase done by init for ARM. There are a few issues with loading ARM executables, most likely due to the alignment of the segments in the linker script (64K) and Twizzler's default page size used in the kernel (i.e. 4K). The current workaround is to load the ELF by manually by copying data into the right place for ARM only. If we are on an x86 system, then we load the executable in pretty much the same way as the dynamic linker (using Twizzler's copy primitive, see
sys_object_create
).The code now gets to a point where init is able to load and run the device manager.
This does not interfere with the upcoming changes implementing the dynamic linker, and are self-contained to ARM targets. Until we can narrow down, why
sys_object_create
does not work or how to change the default alignment, loading for aarch64 is going to be a little different.