Load modules and resolve functions in crt0

[173210]

NOTE:
This is just a concept and I have not tested yet.
This breaks some compatibility.

You no longer have to write initializing functions at the beginning of _main. The new crt0 resolves only functions we need. So it's easier to use and doesn't waste memory.
This change also removes redundant code (+163, -465) in old resolving code and allow you to add functions with less code.

Please note that I have not tested because I don't have a PS4. I have some concerns:

• Module Reloading
  I found a code to reload libScePad module in an example. I applied the trick to all codes to keep the code simple. I know the overhead is very small, but it may cause a problem.
• Loading all modules with loadModule
  All modules will be loaded with loadModule although some of the current initializers use sceKernelLoadStartModule.
• Position Independent Code
  This change is incompatible with position independent code. It's possible to support position independent code, but you have to resolve the GOT.

[hitodama]

Hi and thanks!

Because some of the concerns could help myself, could you clarify them a bit?

Why do you want to reload modules?

• Because we are in a running process and may need to reload them to properly work?
  • Do you have an example where this is needed?

Whats the primary rational of using loadModule over sceKernelLoadStartModule?

• Speed? You are gonna load libkernel anyway, no?
• I think CTurt migrated to LSM because LM was causing problems (you needed to run the inits).

Concerning the ELF PIE: For poking the kernel it doesn't seem necessary, right now. For later I think its definitively the target. Either the official out off-process or our small in-process loader can handle it. It is implemented but not used (needed) right now.

I like your loading approach, it is certainly an improvement over doing it manually. I did the same a while back, but instead of resolving all functions I use a lazy loading (trampoline) approach which just loads the functions as needed (https://github.com/ps4dev/libps4-boilerplate#resolution-process-and-overhead).

• It allows me to include FreeBSD headers directly (official SCE headers probably too - I don't have them, but hey maybe some official def wants to go slim ^^).
• I don't load unneeded functions (specifically for a huge libc that seems SLOW)
  • This is my main rational for doing it as a trampoline, thoughts?
• I do add a jump of indirection per lib call (trampoline). Do you have insights on (real) speed impacts? I don't patch the function directly yet (RO .text) but inevitably I could of course.
• I don't have to think about linker scripts or Makefiles ... which I tend to shy away from Oo!

I like to thank you for your Makefile approach to Stub generation (!). I think I will apply the idea to my code.

Kind regards and thanks again,
Hito

[173210]

• Because we are in a running process and may need to reload them to properly work?
  • Do you have an example where this is needed?

I mean, an example for pad in examples directory (e100c7f)

Whats the primary rational of using loadModule over sceKernelLoadStartModule?

Because it's very easy to implement if it loads all modules only with a function. That's all. I'll fix it right now.

Concerning the ELF PIE: For poking the kernel it doesn't seem necessary, right now. For later I think its definitively the target. Either the official out off-process or our small in-process loader can handle it. It is implemented but not used (needed) right now.

If the kernel can resolve GOT, it's easy to add the feature later.

[173210]

24dfd9f allows to use sceKernelLoadStartModule.