toggle quoted messageShow quoted text
Sorry, just saw this. There are some k_mem_partitions defined which can help with this, z_malloc_partition and z_libc_partition.
z_malloc_partition is for the malloc() arena, which is global.
z_libc_partition is for any other globals associated with the libc.
These are defined in include/sys/libc-hooks.h along with the further comments.
This situation is not ideal. We would eventually like separate libc library globals and malloc arenas on a per memory domain basis (not per thread). This is, to put it mildly, tricky to do when all you have is an MPU. There's a issue here about it: https://github.com/zephyrproject-rtos/zephyr/issues/25891
the last comment has my current thinking on this problem.
From: email@example.com <firstname.lastname@example.org> On
Behalf Of Keith Packard via lists.zephyrproject.org
Sent: Saturday, September 19, 2020 2:06 PM
Subject: [Zephyr-devel] Memory protection and picolibc global state
I'm continuing to develop picolibc (https://github.com/picolibc) support for
Zephyr under this PR:
I'm running the sanity checks under qemu on mps2_an521 which uses the
ARM MPU. On this board, the default memory protection configuration
seems to place all libc globals in a region which is protected against
application access. That includes globals used in managing the malloc heap,
and so application calls to malloc end up generating a MPU fault.
I can fix this in at least a couple of possible ways:
1) Create per-thread malloc heaps and track malloc per-thread.
2) Figure out how to change protection for libc globals
3) Replace the picolibc malloc implementation with a Zephyr custom