Function deletions. With the move from p2p to client-server, large parts of the networking code will go unused. We should keep track of them and reuse the space to put our custom functions.
Data deletions. They are useful for the same reasons, although their use is more limited because data is often shared by multiple functions in the same translation unit.
Function replacements. This includes the ability to call the original function from the replacement if needed.
Data replacements (similar to 0x gecko codes). This allows us to change constants and to apply simple asm patches.
Asm insertions (similar to c2 gecko codes). For when we want to patch a small part of a not well understood function.
Patches will be applied just before the execution of the dol/rel entry points. Hot patching will not be supported in any way.
If we don't get enough space from deletions, we will simply allocate memory from the MEM1 heap. Fixing the position of the bss section of the rel is a separate issue.
An unresolved question is: when to apply relocations? It might be simpler to do it during the build process, but that has the following drawbacks:
~We would need to know the start address of the rel at build time, and any change to memory allocations in the dol will change it. We can run the dol and look at the result but that's somewhat hacky.~ Actually wrong, StaticR.rel has its own heap.
The main.elf will be slightly larger because all the patches will need one version per region.
We want to support 5 types of patches:
Patches will be applied just before the execution of the dol/rel entry points. Hot patching will not be supported in any way.
If we don't get enough space from deletions, we will simply allocate memory from the MEM1 heap. Fixing the position of the bss section of the rel is a separate issue.
An unresolved question is: when to apply relocations? It might be simpler to do it during the build process, but that has the following drawbacks: