ElfLoad read the entire binary into one kernel heap allocation before copying segments out. The heap grows through ReallocConsecutive, so a 40 MB cc1plus required 10k physically contiguous pages - effectively impossible after boot with a 368 MB ramdisk module resident, and the failed spawn surfaced as posix_spawnp ENOENT in the gcc driver. The loader now reads the ELF header and program header table (bounded at 64 entries), then copies each PT_LOAD page and the PT_TLS template directly from the VFS into freshly mapped process pages. Peak kernel memory per load drops from fileSize to one page regardless of binary size. Boot-smoke verified: all userspace loads through this path. Co-Authored-By: Claude Fable 5 <[email protected]>
16 lines
439 B
C++
16 lines
439 B
C++
/*
|
|
* BuildNo.hpp
|
|
* Monotonic kernel build number.
|
|
*
|
|
* This file is the source of truth for the build number. It is regenerated
|
|
* (incremented) by scripts/bump-build.sh whenever the kernel or userspace
|
|
* sources change, via a rule in kernel/GNUmakefile. Do not edit the number
|
|
* by hand; the build system manages it.
|
|
*
|
|
* Copyright (c) 2026 Daniel Hammer
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#define MONTAUK_BUILD_NUMBER 23
|