[Qemu-devel] [PATCH] linux-user: Allocate extra space for brk in PIE executable

[Richard Henderson <richard.henderson@linaro.org>]

Limit this to 16M; there does not appear to be any special
support for this in the kernel itself, at least for i686.

Fixes: https://bugs.launchpad.net/bugs/1749393
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---

Commentary in the launchpad bug suggests 128M gap for x86_64, but that's
somewhat irrelevant to the given i686 test case.  There's certainly nothing
in the referenced kernel patch that does any more than we had been doing
without this patch.

I'm not sure what other limits on extra_size might we want to impose.
With -R set to something less than the full address space we could easily
wind up asking for more space than is available.


r~
---
 linux-user/elfload.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 9d10a5f592..e51d441fb9 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2055,7 +2055,15 @@ static void load_elf_image(const char *image_name, int image_fd,
            image is pre-linked, LOADDR will be non-zero.  Since we do
            not supply MAP_FIXED here we'll use that address if and
            only if it remains available.  */
-        load_addr = target_mmap(loaddr, hiaddr - loaddr, PROT_NONE,
+        abi_ulong total_size = hiaddr - loaddr;
+        if (pinterp_name != NULL) {
+            /* This is the main executable.
+             * Hack to reserve some extra space for brk.
+             */
+            abi_ulong extra_size = 16 * 1024 * 1024;
+            load_addr = mmap_find_vma(loaddr, total_size + extra_size);
+        }
+        load_addr = target_mmap(load_addr, total_size, PROT_NONE,
                                 MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
                                 -1, 0);
         if (load_addr == -1) {
-- 
2.14.3