REL (File Format): Difference between revisions

Jump to navigation Jump to search
m
>Aruki
>Aruki
Line 272: Line 272:
=== Relocation Table ===
=== Relocation Table ===


This data is pointed to by the ''Relocation Table Offset'' value in the header. Since modules have space allocated at runtime and therefore do not have a fixed memory address, the relocations table is needed to ensure all data and function addresses are correct; this includes both symbols within the REL itself, which don't have a fixed address until the REL is linked in, and symbols within the DOL, which need corrections due to the usage of relative offsets in branch instructions. The relocation table describes the location of every instruction that needs to be patched, and how to patch it.
This data is pointed to by the ''Relocation Table Offset'' value in the header. Since modules have space allocated at runtime and therefore do not have a fixed memory address, the relocations table is needed to ensure all data and function addresses in the REL are correct; this includes both symbols within the REL itself, which don't have a fixed address until the REL is linked in, and symbols within the DOL, which need corrections due to the usage of relative offsets in branch instructions. The relocation table describes the location of every instruction that needs to be patched, and how to patch it.


There are multiple distinct groups of relocations, with each one being pointed to by an entry in the [[#Import Table|import table]]. To read the relocations for a given module, you need to iterate over all relocation entries until you hit an R_DOLPHIN_END directive. Each relocation is 0x8 bytes.
There are multiple distinct groups of relocations, with each one being pointed to by an entry in the [[#Import Table|import table]]. To read the relocations for a given module, you need to iterate over all relocation entries until you hit an R_DOLPHIN_END directive. Each relocation is 0x8 bytes.
Anonymous user

Navigation menu