Date: Wed, 23 Mar 2022 18:05:08 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262378] emulators/wine-devel won't start on CURRENT due to ASLR changes Message-ID: <bug-262378-227-fAnmuXdUgE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262378-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262378-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262378 --- Comment #11 from Damjan Jovanovic <damjan.jov@gmail.com> --- 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, wh= ich frees up 0x7ffe0000 - 0x7ffe1000 which Wine needs. Setting kern.elf64.aslr.stack=3D0 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=3D1, and what determines its placement in memory? Who= does that, libc, rtld-elf, the kernel? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262378-227-fAnmuXdUgE>