Tunable / (Per-platform) Stack Sizes about cosmopolitan HOT 4 CLOSED

What you propose was a sensible thing to do, until about seven minutes ago.

I'm proud to announce that Cosmopolitan now has malloc() support on metal. See edd9297 where I've updated the APE bootolader so that it reads the ELF program headers and maps whatever they define into memory. We use the PT_GNU_STACK program header to define the fixed address and size of the stack consistently for all operating systems. (Although officially speaking the only thing PT_GNU_STACK has historically done is it tells the Linux kernel to make mprotect actually protect memory rather than its default behavior of doing nothing and returning zero lool).

Is this recent change sufficient to meet your needs? I've got metal into a pretty good state right now. The next change is likely going to be interrupt handling, since right now all faults are triple faults without backtraces and life is going to be so much easier when that's no longer the case.

from cosmopolitan.

(I don't plan to distribute these binaries; they will only run on Linux / bare-metal machines that have known / controlled specs)

from cosmopolitan.

Thank you! This is awesome. It sounds like malloc Just Works, and I can get my ridiculous 32GB stacks from (slightly abusing?) the PT_GNU_STACK program header (I haven't tried this yet).

from cosmopolitan.

You can do both! Stacks can be huge and dynamic memory should just work too. The x86_64 architecture basically requires us to have a dynamic virtual memory manager in order to be able to run 64-bit instructions. I've managed to make the cost of having that no more than 12kb. But obviously the footprint will grow as you start linking functions like malloc().

I'm going to close this out since we've got a centralized tuning knob for stack size across all platforms now. Let me know if you'd like a way to make configuration easier. Possibly by having an optional macro that can be defined.

from cosmopolitan.