Date: Wed, 23 Mar 2022 18:05:08 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262378 --- Comment #11 from Damjan Jovanovic <firstname.lastname@example.org> --- The large mapping exists even at the start of mmap_init() in that file, and at the start of its caller, virtual_init(). Starting at the beginning, and patching main() in loader/main.c to also dump /proc/curproc/map, shows that the large mapping exists even at the start of main() :-(. But why is that absent in my test binary? Actually, my test binary also has that large mapping: 0x80063e000 0x82061e000 0 0 0 --- 0 0 0x0 NCOW NNC none - NCH -1 but it is situated much higher up in memory: starting at addresses around 0x80063e000 (beyond the 4th GiB), instead of around 0x62bd6000 for Wine, which frees up 0x7ffe0000 - 0x7ffe1000 which Wine needs. Setting kern.elf64.aslr.stack=0 seems to make that large mapping go away, so it looks to be a FreeBSD 14-CURRENT ASLR thing after all. Does anybody know why we allocate this 0x1ffe0000 byte long mapping when kern.elf64.aslr.stack=1, and what determines its placement in memory? Who does that, libc, rtld-elf, the kernel? -- You are receiving this mail because: You are the assignee for the bug.