All this is a bit too weird to be honest. I dug into it a bit more and found out that I've had ASLR enabled pretty much since I started working on dfhack, with a 64bit kernel.
This is with ASLR enabled (/proc/sys/kernel/randomize_va_space set to 2):
08048000-08b39000 r-xp 00000000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b39000-08b3a000 r--p 00af0000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b3a000-08b3b000 rw-p 00af1000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b3b000-09578000 rw-p 00000000 00:00 0
0a1e8000-1c97f000 rw-p 00000000 00:00 0 [heap]
There's a clear distinction between the heap (0a1e8000-1c97f000) and the 'static data' (08b3b000-09578000). All the addresses in Memory.xml actually point into this 'static data' area. The binary contains pointers into this area (for example a static 'WORLD' pointer is used all over the place).
Now this is how the memory layout looks like without ASLR:
08048000-08b39000 r-xp 00000000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b39000-08b3a000 r--p 00af0000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b3a000-08b3b000 rw-p 00af1000 08:01 303572 /home/peterix/DF2010/libs/Dwarf_Fortress
08b3b000-09ac4000 rw-p 00000000 00:00 0 [heap]
f3ea7000-f3f83000 rw-p 00000000 00:00 0
No 'static data' area, only heap. I'll do some testing with my automated offset search tool and report back
Edit:
OK. the tool crashes and burns without ASLR. It actually makes the binary easier to hack... lol.WTF.