💾 Archived View for bbs.geminispace.org › u › stack › 5079 captured on 2023-12-28 at 16:34:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Re: "Address Randomization Tribulations"
I was completery right.
Tried with gdb (yuck), after `set disable-randomization off`, to turn randomization on, because gdb turns randomization off by default (wasting a bunch of my time, but kind of almost doesn't make no sense, pun intended).
(gdb) info proc mappings
process 144876
Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile
0x8048000 0x804a000 0x2000 0x0 rwxp /home/stack/src/nForth/nforth
0x87df000 0xa049000 0x186a000 0x0 rwxp [heap]
0xf7f75000 0xf7f79000 0x4000 0x0 r--p [vvar]
0xf7f79000 0xf7f7b000 0x2000 0x0 r-xp [vdso]
0xffc4e000 0xffc6f000 0x21000 0x0 rwxp [stack]
(gdb)
So, nforth loads at 0x0804800-0x0804A00, but when heap is expanded up, it starts at 0x087DF000 and goes to 0x0A04900. So the memory space is not contiguous, and the entire idea of sysbreak is bullshit, in this particular case.
Sep 03 · 4 months ago
Address Randomization Tribulations — So, I have a tiny 32-bit application (a Forth) taking up about 4K, written in fasm. Pure minimalism, including an iffy elf header that fasm creates, with a fixed load address. More on that later. It's been unstable, and I tracked the instability down to the initial memory allocation. Right at the start I add my desired memory size to the code base (the top label in asm code), and invoke `brk` system call. This worked as long as I allocated a largish...