feature : change HBC loader to support loading 'loaders'

[DacoTaco]

The HBC binary loader rejects things that use up the MEM1 memory range used by loaders, so it doesn't overwrite itself or its framebuffer.
thats all good and well, but this prevents me from developing priiloader safely as my entrypoint is in said range.

Priiloader contains a loader that supports this by loading the binary, and a loader, to mem2 and executing the loader that loads the dol/elf.

ive currently had to create some bootloader that loads Priiloader just to make it work in HBC, which i'd prefer to not be there, as its hacky shit.

[dhewg]

preloader, really? :P

Anyway, the 0x1800 thingy won't change at this point, you need to use a trampoline. But you can just do it like hbc does when uploading it to itself: pack it with wiipax

[DacoTaco]

*priiloader, but yes :)

also, its not 0x1800, i keep that free for the hbc stub, for libogc obviously. i meant the 0x81330000 range, used by loaders&system menu on the wii.

i have currently created my own trampoline, using my loader, but it feels hacky as HBC could be changed to allow them to be loaded, including itself.
since wiipax already has a loader, that code could even be reused..

[dhewg]

Sure, we could add something to hbc. But for one, I don't see anyone publishing a hbc release, and even then it'll mean that all your users need to update for you to get rid of your trampoline. Using wiipax gives you both, and more, now.

[DacoTaco]

my users, is just me and anyone who is developing priiloader. generic users have no use to this change, this is pure for developers and myself.

however, even if we see this as a change for all users/homebrew to use, then the whole trampoline system still sounds hacky, as its perfectly possible to drop that need, making it easier for anyone to develop, have less steps in build and less steps that could go wrong..

and the publishing issue of HBC is a different discussion to have imo, not fit to have here since we have #10 where it was discussed.

[dhewg]

I don't agree on the hacky part, the only way to avoid every possible overlap is to use a trampoline.
But whatever, what's the point in discussing it if there's not going to be a release anyway?

I vaguely remember that we had some sort of trampoline for this in hbc, which we got rid of in favor of wiipax. Compressing and uploading a compressed binary was faster than uploading an uncompressed one. You're welcome to just reuse it and get rid of your local hacks. It's a easy as make upload in hbc's channelapp.

[DacoTaco]

make upload will run wiiload, which just sends it to HBC to run, so im not sure why you mention that? if HBC would accept loaders range binaries, it would just be make run for me too and not require some added target to make a runable binary.

its your wiipax, and my trampoline, usage that makes it runable, smaller for wiiload to send (even though wiiload also compresses the binary and its sending the elf, but i digress ).

i understand originally wiipax was required for the obfuscation etc etc but as is, it has no usage besides compression if you want it and made HBC not have the issue at all. i don't need all those things.

as for the overlap, thats correct. you can't kill all overlap. in priiloader however, i load both binary and loader to mem2 and i have yet to see an binary that has sections in mem2, so the chances of overlap are low.

(and imo, HBC needs another release and maybe a new system so it is easier to release. but again, thats for the other issue to discuss in)

[dhewg]

I can only think of so many iterations of saying the same thing, last try:

hbc can't directly accept your loader range because hbc sits there itself. So need a trampoline for that.
wiipax provides one. A wiipaxed compressed binary won't have a LOAD phdr at your loader address even if the uncompressed binary has one.
Which is why make upload works without its own trampoline. How else could it work? It provides a solution to the very same problem.

[DacoTaco]

same for me though. priiloader can load any binary in any memory range, even if it were to overwrite itself.
this is done by moving all required data (loading code+binary) to somewhere else (somewhere in MEM2 in my case) and load it.
aka the logic and concern is all in the loaders hands, not the binary being loaded.
a lot cleaner, a lot less overhead, and a lot less hacking around stuff.
the loader doesn't even need to be big, my loader is ~0x1000 bytes but has its own stack and some of the system menu patches logic in it.

if i can do it, HBC can also do it (but probably better).

but ye, our discussion is going nowhere it seems.