Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

uyjulian
Copy link
Member

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
Copy link
Member

fjtrujy commented Dec 25, 2023

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

@uyjulian
Copy link
Member Author

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
Copy link
Member

sp193 commented Dec 27, 2023

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants