REL (File Format) - Revision history

>Aruki: /* Relocation Table */

2017-02-17T19:15:12Z

Relocation Table

← Older revision		Revision as of 19:15, 17 February 2017
Line 299:		Line 299:
	\| 1		\| 1
	\| '''Section Index'''		\| '''Section Index'''
	\| The section index of the symbol being patched to.		\| The section index of the symbol being patched to. This is only used for module patches.
	\|-		\|-
	\| 0x4		\| 0x4

>Aruki: /* Header */

2016-10-31T03:10:15Z

Header

← Older revision		Revision as of 03:10, 31 October 2016
Line 165:		Line 165:
	\| 1		\| 1
	\| '''Prolog Function Offset'''		\| '''Prolog Function Offset'''
	\| Section-relative offset of the prolog function. 0 if this module doesn't contain a prolog function.		\| Section-relative offset of the prolog function. 0 if this module doesn't contain a prolog function. This is converted into a function pointer at runtime by OSLink.
	\| {{check}}		\| {{check}}
	\| {{check}}		\| {{check}}
Line 174:		Line 174:
	\| 1		\| 1
	\| '''Epilog Function Offset'''		\| '''Epilog Function Offset'''
	\| Section-relative offset of the epilog function. 0 if this module doesn't contain an epilog function.		\| Section-relative offset of the epilog function. 0 if this module doesn't contain an epilog function. This is converted into a function pointer at runtime by OSLink.
	\| {{check}}		\| {{check}}
	\| {{check}}		\| {{check}}
Line 183:		Line 183:
	\| 1		\| 1
	\| '''Unresolved Function Offset'''		\| '''Unresolved Function Offset'''
	\| Section-relative offset of the unresolved function. 0 if this module doesn't contain an unresolved function.		\| Section-relative offset of the unresolved function. 0 if this module doesn't contain an unresolved function. This is converted into a function pointer at runtime by OSLink.
	\| {{check}}		\| {{check}}
	\| {{check}}		\| {{check}}

>Aruki: /* Relocation Table */

2016-10-02T17:17:50Z

Relocation Table

← Older revision		Revision as of 17:17, 2 October 2016
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.

>Aruki: /* Relocation Table */

2016-10-02T16:52:03Z

Relocation Table

← Older revision		Revision as of 16:52, 2 October 2016
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 ~~references to~~ symbols within the REL have ~~the correct~~ address~~. When~~ the ~~module~~ is linked in, the ~~game uses~~ the relocation table to ~~iterate over all instructions~~ and ~~data values referring~~ to ~~REL symbols, and~~ patch ~~them to point to the correct address~~.		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.

	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.

>Aruki: /* Relocation Table */

2016-10-01T18:42:22Z

Relocation Table

← Older revision		Revision as of 18:42, 1 October 2016
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 ~~can~~ therefore do not have a fixed memory address, the relocations table is needed to ensure all references to symbols within the REL have the correct address. When the module is linked in, the game uses the relocation table to iterate over all instructions and data values referring to REL symbols, and patch them to point to the correct address.		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 references to symbols within the REL have the correct address. When the module is linked in, the game uses the relocation table to iterate over all instructions and data values referring to REL symbols, and patch them to point to the correct address.

	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.

>Aruki: /* Relocation Table */

2016-10-01T18:17:53Z

Relocation Table

← Older revision		Revision as of 18:17, 1 October 2016
Line 366:		Line 366:
	\| 9		\| 9
	\| R_PPC_ADDR14_BRNTAKEN		\| R_PPC_ADDR14_BRNTAKEN
	\| Write the 14-bit address of the symbol. Leave the existing value of the bottom two bits intact. '''Note:''' Needs a proper check on ~~the~~ differences between this and ADDR14		\| Write the 14-bit address of the symbol. Leave the existing value of the bottom two bits intact. '''Note:''' Needs a proper check on differences between this and ADDR14
	\| {{nocheck}}		\| {{nocheck}}
	\|-		\|-

>Aruki at 17:55, 1 October 2016

2016-10-01T17:55:33Z

← Older revision		Revision as of 17:55, 1 October 2016
Line 4:		Line 4:

	== Format ==		== Format ==

	The REL format is split up into a number of different sections, just like an ELF file. Sections that were generated by the compiler but aren't used by the game (such as the sections for relocations or symbols) are nulled out and listed with an offset and size of 0.

	=== Header ===		=== Header ===
Line 233:		Line 231:
	\| 1		\| 1
	\| '''Offset'''		\| '''Offset'''
	\| ~~Offset~~ of the section. The 0x1 bit is toggled to indicate whether this section contains executable code. AND out that bit to get the correct offset.		\| Absolute offset of the section. The 0x1 bit is toggled to indicate whether this section contains executable code. AND out that bit to get the correct offset.
	\|-		\|-
	\| 0x4		\| 0x4

>Aruki: /* Header */

2016-10-01T17:39:27Z

Header

← Older revision		Revision as of 17:39, 1 October 2016
Line 95:		Line 95:
	\| 1		\| 1
	\| '''BSS Size'''		\| '''BSS Size'''
	\| Size of the BSS section, which is allocated at runtime (not included in the file)		\| Size of the BSS section, which is allocated at runtime (not included in the file).
	\| {{check}}		\| {{check}}
	\| {{check}}		\| {{check}}

>Aruki: /* Format */

2016-10-01T17:36:00Z

Format

← Older revision		Revision as of 17:36, 1 October 2016
Line 67:		Line 67:
	\| u32		\| u32
	\| 1		\| 1
	\| '''Name Offset'''		\| '''Module Name Offset'''
	\| Offset to the module name. Can be 0, in which case this module doesn't contain a name string.		\| Offset to the module name. Can be 0, in which case this module doesn't contain a name string.
	\| {{check}}		\| {{check}}
Line 76:		Line 76:
	\| u32		\| u32
	\| 1		\| 1
	\| '''Name Size'''		\| '''Module Name Size'''
	\| Size of the module name string.		\| Size of the module name string.
	\| {{check}}		\| {{check}}

>Aruki: /* Header */

2016-10-01T17:23:16Z

Header

@@ Line 60: / Line 60: @@
 | '''Section Info Offset'''
 | Offset to the [[#Section Info Table|section info table]].
 | {{check}}
 | {{check}}