[libc] Lazily initialize freelist malloc using symbols #99254

This allows the user to customize the size of the heap provided by overriding the weak symbol __libc_heap_limit at link time. The heap begins at _end and ends __libc_heap_limit bytes afterwards. It also prevents a completely unused heap from requiring any space. (It's reasonably common to link in malloc/free to handle exceptional situations that can never actually be encountered.) I'd think this should eventually be replaced with an implemenation based on sbrk(), with sbrk() implemented generically in terms of brk(), which would be a system call on e.g. Linux and a bump pointer from _end up to __libc_heap_limit on baremetal. This would allow the allocator to be more flexible (e.g., an implementation could swap out brk() and do dynamic memory availability checks), to manage the heap better by keeping better track of "wilderness" and to work properly as a malloc on Linux. Incidentally, this sets the default heap limit to 128KiB, from 102400 bytes, which had been reported as "1GiB".

- Move preprocessor check to assembly file - Add LIBC_CONSTINIT back to heap definition; make non-constexpr cast from &__heap_limit to size_t occur at init time to restore constexpr init.

This is more conventional and it dodges the issue of needing to provide a default size entirely. Setting up a baremetal heap intrinsically requires some linker script work, and __libc_heap_limit will be an undefined reference hinting to the user that this work must be done. Once we have a morecore function, a baremetal morecore() would use __libc_heap_limit, a Linux one would use sbrk(), and a test one would use a buffer.

- __libc_heap_limit -> __llvm_libc_heap_limit

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[libc] Lazily initialize freelist malloc using symbols #99254

[libc] Lazily initialize freelist malloc using symbols #99254

Commits on Jul 25, 2024