How do relocations work in COFF object (not image) files

Question

What steps exactly are taken by the linker while resolving relocations in an object file before creating the final image? More specifically, how does the linker treat the value which is already stored at the relocation site? Does it always add it to the final VA/RVA, or is it sometimes ignored (e.g certain relocation types)?

I couldn't find a clear explanation in the MS PE/COFF Specfication, and after googling and experimenting for a while, all I could find out was this:

1. In the MS COFF spec, chapter 5.6.2 "Base Relocation Types", it is said that "The base relocation applies all 32 bits of the difference to the 32-bit field at offset", which I guess means that the relocation should take into account whatever address is already stored at the specified offset. However, chapter 5.6 (the .reloc section) is only relevant to image files, and not object files.
2. The dumpbin utility adds a column named "Applied To" when printing the relocations table, which seems to always (no matter the relocation type) contain the value which is stored at the relocation site.
3. The Relocation Directives chapter in the DJGPP COFF Specification clearly states that the value currently stored at the location should be added to the address of the symbol pointed to by the relocation table entry.

Can you point me to any (relevant) documentation which explains how relocations are handled by the linker?

Slightly

Isn't the appropriate section for object files 4.2 "COFF Relocations" and not section 5.6.2 which is only for image files? – Tachistoscope

It should be, but section 4.2 doesn't explain what to do if the relocation site has a value different from 0 stored in it, which is actually quite common, and can be easily seen using dumpbin. – Slightly

Answer 1

The relocation section used in "image files" has a slightly different purpose from the relocation information present in "object files".

Unlike Linux Shared Libraries, Windows DLLs do not typically use position independent code. Instead they are defined relative to a fixed based address. The Windows loader, however, has the ability to relocate a DLL in the event of a conflict. To support this, DLL images contain relocation sections that specify what data needs to be modified when the image is relocated. Many intra-dll symbol references will use "eip" (or rip) relative addressing, so they may not need to be modified on DLL relocation.

Image file relocations are always specified relative to the base address of the executable image. Object file relocations are specified relative to the address (within an image, using the images preferred based address) of a symbol in a symbol table. Image files don't have a symbol table (they have an IAT, but that's not a symbol table). The set of supported relocations in object files is richer then the set supported in image files.

The details are covered in the "COFF Relocations (Object Only)" section of the PE/COFF spec (I'm looking at version 3 as I type this).

Battement