Initial rewrite of elf-loader to use mostly code on EE

[uyjulian]

This is intended to allow better debugging and error handling. So the conditions causing either black screen or return to OSDSYS are significantly lower.

The con of this method is that it requires free EE memory. But this should not be a major issue as executables should be packed with ps2-packer, and non-loadable sections are not loaded in memory.

Pending testing by myself

[fjtrujy]

Does it mean that ALL binaries then must be compressed with ps2-packer?

[uyjulian]

Nope, it doesn't necessarily mean that it requires ps2-packer. It only loads any LOAD program segments so stuff like debug information and symbols won't be loaded in memory. ps2-packer just gives a better size for that situation.

If size of uncompressed binaries fitting in memory is actually an issue then it could be possible to add in-memory compression later.

[sp193]

Personally, I feel that there's no need to reinvent the wheel. This method you refer to, does have its own uses. But the PS2's kernel design always had the kernel (includes the IOP side, which is LOADFILE) to load executables in mind, so that the higher-level developers did not have to write such code.

If the goal is to show how else an ELF can be loaded, should we have another example so that the standard method remains as the de-facto way?

Why can't an ELF be loaded anyway, if it is made by the same toolchain? I think that most people wouldn't run into such problems that require them to debug the ELF-loading process, which then probably entails some fix to the toolchain.

[uyjulian]

Personally, I feel that there's no need to reinvent the wheel. This method you refer to, does have its own uses. But the PS2's kernel design always had the kernel (includes the IOP side, which is LOADFILE) to load executables in mind, so that the higher-level developers did not have to write such code.

This is mainly one step towards in-memory ELF loading from EE (such as from an HTTP(S) server using libcurl).

If the goal is to show how else an ELF can be loaded, should we have another example so that the standard method remains as the de-facto way?

I think it would be a good idea to add an example for using LoadExecPS2.

Why can't an ELF be loaded anyway, if it is made by the same toolchain? I think that most people wouldn't run into such problems that require them to debug the ELF-loading process, which then probably entails some fix to the toolchain.

There are cases where stuff like loading in the same address space as the application (when not using LoadExecPS2/EELOAD e.g. ps2link) or attempting to load into scratchpad (this doesn't work) is attempted. It is mainly an attempt to codify the failure cases to bail out early and indicate why it would fail.

[uyjulian]

This now fixes some issues in elf-loader causing hang on a black screen (possibly due to LOADFILE memory allocation pattern bugs).

Testing a patched wLE using the elf-loader library, it can now run itself and OPL from a USB storage device without hanging on a black screen.

This also opens the door to implement archive and network ELF loading more easily.

[fjtrujy]

I think that we should keep the previous elf-loader and if you want you can create another extra one.
Based on my experience, in the past when I have been facing black screens they have been related to running out of IOP memory, most probably it was about the #715

[uyjulian]

It has been made into another library