Difference between revisions of "REL (File Format)"
m (→Tools: This is the REL page) |
m |
||
Line 224: | Line 224: | ||
* [[StaticR.rel Tool]], by [[Atlas]], can edit the region number, plus HUD, region line, Mii suit and layout buttons colors from the same file. | * [[StaticR.rel Tool]], by [[Atlas]], can edit the region number, plus HUD, region line, Mii suit and layout buttons colors from the same file. | ||
− | [[ | + | [[Category:File Format/Wii]] |
Revision as of 20:38, 15 June 2017
REL files are relocatable object files used by Nintendo. Mario Kart Wii features one such file: StaticR.rel. In general these files allow extra code to be loaded as needed by games, especially when the memory footprint becomes a concern. In Mario Kart, the REL code contains much of the Mario Kart specific logic, such as gameplay, and, once loaded during the health and safety screen, remains loaded for the entire run of the application. Information about specific alteration that can be made to the Mario Kart Wii file can be found here.
File Format
Like many object formats, the file is divided into sections, grouped by like access. For example, all executable code is placed in one section, read only data in another, etc. The file begins with a header, followed by the section info table, followed by the section data, followed by the relocation information.
File Header
The file begins with a header of up to 0x4C bytes:
Offset | Size | Description |
---|---|---|
0x00 | 4 | id: Arbitrary identification number for game use. |
0x04 | 8 | padding? ignored by MKW |
0x0c | 4 | numSections: Number of sections in the file. |
0x10 | 4 | sectionInfoOffset: Offset to the start of the section table. |
0x14 | 4 | nameOffset: Offset to ASCII string containing name of module. May be NULL. |
0x18 | 4 | nameSize: Size of the module name in bytes. |
0x1c | 4 | version: Version number of the REL file format. |
0x20 | 4 | bssSize: Size of the 'bss' section. |
0x24 | 4 | relOffset: Offset to the relocation table. |
0x28 | 4 | impOffset: Offset to imp(?). |
0x2c | 4 | impSize: Size of imp(?). |
0x30 | 4 | flags of some sort? ignored by MKW |
0x34 | 4 | prolog: ? |
0x38 | 4 | epilog: ? |
0x3c | 4 | unresolved: ? |
0x40 | 4 | Version ≥ 2 only. align: Alignment constraint on all sections. |
0x44 | 4 | Version ≥ 2 only. bssAlign: Alignment constraint on all 'bss' section. |
0x48 | 4 | Version ≥ 3 only. fixSize: ? |
0x4c or 0x48 or 0x40 | End of header |
Section Info Table
The section info table comprises of numSections entries each 0x8 bytes long, of the following form:
Offset | Size | Description |
---|---|---|
0x0 | 4 | offset: Location in file of the section information. The last bit determines if this section is executable or not. If this is zero, the section is an uninitialized section. |
0x4 | 4 | length: Length in bytes of the section. |
0x8 | Next entry |
imp
The imp information may be a table. It seems to contain pointers into the relocation information, potentially to allow it to be done in phases. If so, the table contains 0x8 byte entries of the form:
Offset | Size | Description |
---|---|---|
0x0 | 4 | type: Type of the relocation entries. 1 for internal, 0 for external. |
0x4 | 4 | offset: Offset from the beginning of the REL to the relocatino data. |
0x8 | Next entry |
Relocation Data
The relocation data seems to be heavily based on the ELF relocation format. It is a list of 0x8 byte structures, and must be parsed in order. Each entry has the form:
Offset | Size | Description |
---|---|---|
0x0 | 2 | offset: Number of bytes to skip before this relocation. |
0x2 | 1 | type: The relocation type. Described below. |
0x3 | 1 | section: The section of the symbol to locate. |
0x4 | 4 | address: Address of the symbol in the section. |
0x8 | Next entry |
The followng relocation types are known[1]:
Type | Name | Description |
---|---|---|
0 | R_PPC_NONE | Do nothing. Skip this entry. |
1 | R_PPC_ADDR32 | Write the 32 bit address of the symbol. |
2 | R_PPC_ADDR24 | Write the 24 bit address of the symbol divided by four shifted up 2 bits to the 32 bit value (for relocating branch instructions). Fail if address won't fit. |
3 | R_PPC_ADDR16 | Write the 16 bit address of the symbol. Fail if address more than 16 bits. |
4 | R_PPC_ADDR16_LO | Write the low 16 bits of the address of the symbol. |
5 | R_PPC_ADDR16_HI | Write the high 16 bits of the address of the symbol. |
6 | R_PPC_ADDR16_HA | Write the high 16 bits of the address of the symbol plus 0x8000. |
7 - 9 | R_PPC_ADDR14 | Write the 14 bits of the address of the symbol divided by four shifted up 2 bits to the 32 bit value (for relocating conditional branch instructions). Fail if address won't fit. |
10 | R_PPC_REL24 | Write the 24 bit address of the symbol minus the address of the relocation divided by four shifted up 2 bits to the 32 bit value (for relocating relative branch instructions). Fail if address won't fit. |
11 - 13 | R_PPC_REL14 | Write the 14 bit address of the symbol minus the address of the relocation divided by four shifted up 2 bits to the 32 bit value (for relocating conditional relative branch instructions). Fail if address won't fit. |
200 | R_RVL_NONE | Do nothing. Skip this entry. Carry the address of the symbol to the next entry. |
201 | R_RVL_SECT | Change which section relocations are being applied to. Set the offset into the section to 0. |
202 | R_RVL_STOP | Stop parsing the relocation table. |
The loader walks this table obeying each command until it encounters R_RVL_STOP. In the case of internal relocations, the symbol address is calculated by taking the load address of the section section and adding the offset address. For external relocation, the symbol address is just address. The purpose of section in such instances is unknown.
Tools
The following tools can handle REL files:
- BrawlBox, by Kryal & BlackJax
- wstrt (see Wiimms SZS Tools) is able to patch data in the Mario Kart Wii file StaticR.rel.
- StaticR.rel Tool, by Atlas, can edit the region number, plus HUD, region line, Mii suit and layout buttons colors from the same file.