Support relocation kind 0003 and extend IMAGE_REL_ types

[jonahbeckford]

Fixes #29 .

Specifically adds support for:

• IMAGE_REL_AMD64_ADDR32NB. (This is the "relocation kind 0003").

• IMAGE_REL_I386_DIR32NB. (This is the x86 version of the above).

• IMAGE_REL_AMD64_REL32_5. (This is documented but weirdly not implemented).

Tested with my ucrt branch https://github.com/jonahbeckford/flexdll/tree/0.43%2Bucrt where relocation kind 0003 occurs often. It especially occurs in "normal" C libraries (ucvrt; /MD) that are linked into an OCaml executable. None of the tested code used /GS-.

References:

• https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#coff-relocations-object-only
• https://github.com/llvm/llvm-project/blob/279953f1da7d7d0e404638414deec5d1df291c7c/lld/COFF/Chunks.cpp#L113-L158

[nojb]

Just for my own understanding:

• In LLVM, this relocation is implemented by add32(off, s), so that off in LLVM corresponds to ptr->addr in Flexlink and s in LLVM corresponds to s in Flexlink.
• The relocation IMAGE_REL_AMD64_ADDR64 in LLVM (RELOC_ABS in Flexlink) is implemented by add64(off, s + imageBase), so that s + imageBase in LLVM corresponds to s in Flexlink.

Do you understand why the s arguments do not seem to match between the two cases?

[jonahbeckford]

Going one step further, those equations imply that imageBase = 0.

I spent a lot of time looking and I couldn't find out why IMAGE_REL_AMD64_ADDR64 seems to work. The math for all the other relocation kinds make sense.

However, two things ...

1. The /base: base address link.exe option is fixed for OCaml executable to be 0x10000 at

   flexdll/cmdline.ml

   Line 47 in 80496b5

   let base_addr = ref "0x10000"

   
   and also the same in
   

   flexdll/create_dll.ml

   Line 77 in 80496b5

   let image_base = 0x10000l in

   
   for OCaml plugins / stubs.
2. All of the relative relocations from this section of code are translated by:
   

   flexdll/reloc.ml

   Lines 470 to 475 in 80496b5

   	Reloc.abs !machine sect (Int32.of_int (Buffer.length data)) strsym;
   	int_to_buf data pos;
   	Reloc.abs !machine sect (Int32.of_int (Buffer.length data))
   	(Lazy.force secsym);
   	int_to_buf data (Int32.to_int rel.addr);

   
   into absolute relocations by Reloc.abs:

   flexdll/coff.ml

   Lines 437 to 444 in 80496b5

   	module Reloc = struct
   	let abs machine sec addr sym =
   	let rtype =
   	match machine with
   	| `x86 -> 0x06
   	| `x64 -> 0x01
   	in
   	sec.relocs <- { addr = addr; symbol = sym; rtype = rtype } :: sec.relocs

So my suspicion was that the Reloc.abs absolute relocations were being translated at CreateProcess time by ntdll.LdrInitializeThunk (or whatever is reading the PE .reloc section) to complete the imageBase adjustment.

@dra27, any chance you can explain why base_addr (or image_base for DLLs) is not used in the calculations?

(These calculations are undocumented in flexdll and fairly complicated)

[jonahbeckford]

I just noticed that I have not extended the DLL logic at

flexdll/create_dll.ml

Lines 235 to 253 in 80496b5

	match !Cmdline.machine, r.rtype with
	| `x86, 0x06 (* IMAGE_REL_I386_DIR32 *)
	| `x64, 0x02 (* IMAGE_REL_AMD64_ADDR32 *) ->
	(* 32-bit VA *)
	relocs := (rel_rva, `R32) :: !relocs;
	Buf.patch_lazy_int32 buf pos (lazy (Int32.add (Int32.add initial (Lazy.force rva)) image_base))
	| `x64, 0x01 (* IMAGE_REL_AMD64_ADDR64 *) ->
	(* 64-bit VA *)
	assert(read_int32 sdata (pos + 4) = 0l);
	relocs := (rel_rva, `R64) :: !relocs;
	Buf.patch_lazy_int32 buf pos (lazy (Int32.add (Int32.add initial (Lazy.force rva)) image_base))
	| `x86, 0x14 (* IMAGE_REL_I386_REL32 *)
	| `x64, 0x04 (* IMAGE_REL_AMD64_REL32 *) ->
	Buf.patch_lazy_int32 buf pos (lazy (Int32.sub (Int32.add initial (Lazy.force rva)) (Int32.add (Lazy.force rel_rva) 4l)))
	| _, k ->
	Printf.ksprintf failwith "Unsupport relocation kind %04x for %s"
	k r.symbol.sym_name

That DLL logic does use the image_base for IMAGE_REL_AMD64_ADDR64 so at least in that code the IMAGE_REL_AMD64_ADDR64 math makes sense.

I don't really have a way to test that. The stubs/plugins generated by OCaml do not have those relocations (which is also why I didn't notice them).