Changing default stack/_end addresses

[tstack]

Hello, I'm trying to get an APE binary to run on ESXi and running into some issues with the default stack/heap addresses. Most linux binaries just work with ESX, but the APE ones are failing because the virtual address space is somewhat limited. I've changed the stack address via ape_stack_vaddr in the ape.lds file and STACK_CEIL in internal.h. That's enough to get the executable started, but the _end (I think) address of 0x100080000000 is also out-of-range and causes other problems. Can you point in the direction to change this address? I've dug around a bunch, but can't figure out what bits to flip.

Thanks!

[jart]

If you need your APE executables loaded at a number greater than the 4gb mark, I'm not sure if it's possible. There's integer overflow bugs in the GNU BFD Linker that prevent us from doing all our fancy linker relocation hacks. Needless to say, once the executable is loaded into memory, it can remap itself to a higher address, with some heroics.

[tstack]

If you need your APE executables loaded at a number greater than the 4gb mark

Sorry, I wasn't clear, the addresses need to be lower. The allowed range is 0x400000 - 31ff8df3000. I changed the stack address from 0x700000000000 to 0x7000000000 and that got me further.

[jart]

Does it need to be in the 32-bit range? You're correct to go about changing things in the linker script with those variables you mentioned. There's a second hack you will likely need, which is what we do support Windows 7 which is all 32-bit pointers. See https://github.com/jart/cosmopolitan/blob/master/libc/runtime/memtrack.h and https://github.com/jart/cosmopolitan/blob/master/libc/runtime/winmain.greg.c

[jart]

The reason you'll likely need to change the memtrack thing is because I'd ideally want to be able to make the assumption that stack addresses are higher than heap and code. Right now heap by default gets allocated right above the 4gb mark so it never collides with ASAN shadow addresses.

[jart]

Oh hey, you're that guy from Hacker News who expressed interest a week or two ago to use Cosmo for a log file navigator. I'm looking forward to seeing this happen since it's such a good use case.

[tstack]

Doh, I was searching for 0x100080000000 and missed the memtrack.h file since the address has leading zeroes in there. Hacking the address in that file was enough to get things working for the machines I use (macos, linux, esx).

Thanks!