Closed s117 closed 4 years ago
The above two behaviors have two different causes accordingly:
The newlib's malloc implementation contains a too conservative overflow checking. Which limits the size of a single malloc request to 2GB. It is patched by https://github.com/s117/riscv-newlib/commit/0e3a7a5f01514d617bccce9dbb34380088d4c9da
PK clamps the vaddr of the user stack top to 0x80000000. I guess the reason is for RV32 compatibility. But this effectively limited the brk line cannot go over 0x8000000, and the result is the maximum available heap space is less than 2G. It is patched by https://github.com/s117/riscv-pk/commit/b142a14ae3ed8117862636f56f970a8775599356
The above patches were incorporated by commit 6fb31c8.
Some SPEC benchmark like 657.xz requires a large amount of memory. But some weird memory allocator behavior is observed with the newlib 9.2.0 toolchain:
No matter how much physical is simulated (for example, 16GB, spike -m16384 ...)
malloc with a large size (about >2GB) always returns null.
after the program has requested more than 2GB memory (roughly), malloc always returns null.
A test code snippet: