f9461d1ac4
The linker script defines `z_mapped_size` as follows: ``` z_mapped_size = z_mapped_end - z_mapped_start; ``` This is done with the belief that precomputed values at link time will make the code smaller and faster. On Aarch64, symbol values are relocated and loaded relative to the PC as those are normally meant to be memory addresses. Now if you have e.g. `CONFIG_SRAM_BASE_ADDRESS=0x2000000000` then `z_mapped_size` might still have a reasonable value, say 0x59334. But, when interpreted as an address, that's very very far from the PC whose value is in the neighborhood of 0x2000000000. That overflows the 4GB relocation range: ``` kernel/libkernel.a(mmu.c.obj): in function `z_mem_manage_init': kernel/mmu.c:527:(.text.z_mem_manage_init+0x1c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 ``` The solution is to define `Z_KERNEL_VIRT_SIZE` in terms of `z_mapped_end - z_mapped_start` at the source code level. Given this is used within loops that already start with `z_mapped_start` anyway, the compiler is smart enough to combine the two occurrences and dispense with a size counter, making the code effectively slightly better for all while avoiding the Aarch64 relocation overflow: ``` text data bss dec hex filename 1216 8 294936 296160 484e0 mmu.c.obj.arm64.before 1212 8 294936 296156 484dc mmu.c.obj.arm64.after 1110 8 9244 10362 287a mmu.c.obj.x86-64.before 1106 8 9244 10358 2876 mmu.c.obj.x86-64.after ``` Signed-off-by: Nicolas Pitre <npitre@baylibre.com> |
||
|---|---|---|
| .. | ||
| arc | ||
| arm | ||
| common | ||
| nios2 | ||
| posix | ||
| riscv | ||
| sparc | ||
| x86 | ||
| xtensa | ||
| arch_inlines.h | ||
| cpu.h | ||
| syscall.h | ||