DOL file format: header

Introduction

The header is always 0x100 bytes and every number in it is an unsigned big-endian 32-bit value. It is three tables of 18 entries (file offsets, load addresses, sizes) with the same index in each: entries 0 to 6 are the text sections Text0 to Text6, entries 7 to 17 the data sections Data0 to Data10. Then the BSS, the entry point and padding. The layout follows the WiiBrew page on DOL (read through a page summary: the offsets below are the page’s, in our words).

Fields

Offset	Size	Field	Meaning
`0x00`	7 × 4	Text file offsets	Where in the file Text0 to Text6 begin (`0x00` to `0x1B`).
`0x1C`	11 × 4	Data file offsets	Where in the file Data0 to Data10 begin (`0x1C` to `0x47`). Each offset should be a multiple of 32.
`0x48`	7 × 4	Text load addresses	The memory address Text0 to Text6 are copied to.
`0x64`	11 × 4	Data load addresses	The memory address Data0 to Data10 are copied to.
`0x90`	7 × 4	Text sizes	The length in bytes of Text0 to Text6. A size of 0 means the section is not used.
`0xAC`	11 × 4	Data sizes	The length in bytes of Data0 to Data10. WiiBrew: each size should be a multiple of 32 as well, or the GameCube’s IPL and the Wii’s IOS reject the file.
`0xD8`	4	BSS address	The start of the area the loader clears to zero before the program starts.
`0xDC`	4	BSS size	The number of bytes to clear; the BSS has no bytes in the file.
`0xE0`	4	Entry point	The address execution starts at; it is inside a text section.
`0xE4`	28	Padding	Up to the end of the header at `0x100`. Every layout description lists these bytes only as padding.

The maximum is seven text and eleven data sections; most programs use one or two text sections and a handful of data sections (the ones a compiler names .rodata, .data, .sdata and .sdata2, usually). The header does not name the console.

What the viewer checks

These rules are the viewer’s own test for “is this a DOL”, built from the rule above and from what a loader must be able to do. A file named .dol that breaks one of the first group is shown as not a valid DOL.

The file holds the 256-byte header.
Every section that has a size starts at or after 0x100, at a multiple of 32, and ends inside the file.
Every such section’s load address and size lie inside one of the memory windows of the memory map: the 24 MiB of main memory (cached at 0x80000000 or uncached at 0xC0000000) or the Wii’s MEM2 (0x90000000 or 0xD0000000).
No two sections overlap in the file, and none overlap in memory (the cached and uncached addresses are the same memory).
At least one text section is in use, and the entry point is inside one and a multiple of 4.

Only shown as an issue, not a refusal: a size that is not a multiple of 32, a non-zero offset or address on an unused section, non-zero padding, a BSS outside main memory or overlapping a section.

Not described

Known, not yet covered

Reference: whether the loader accepts a size that is not a multiple of 32 (the page says it should be, and that the IPL and IOS reject otherwise: no loader was available to check), what the padding bytes are for in files other tools write, and the valid load address range (the sources do not say; the windows above are the memory the console has).
Viewer: only built files were checked, because no DOL exists on this machine.

Unknown

Whether any real program uses a section in the uncached window or in MEM2 above the first 24 MiB for a GameCube; the viewer accepts them.

DOL File Format – Header