Laurent Vivier <laur...@vivier.eu> writes:
> Le 16/12/2021 à 15:44, Alex Bennée a écrit : >> The pgb_find_hole function goes to the trouble of taking account of >> both mmap_min_addr and any offset we've applied to decide the starting >> address of a potential hole. This is especially important for >> emulating 32bit ARM in a 32bit build as we have applied the offset to >> ensure there will be space to map the ARM_COMMPAGE bellow the main >> guest map (using wrapped arithmetic). >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/690 >> --- >> linux-user/elfload.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> diff --git a/linux-user/elfload.c b/linux-user/elfload.c >> index 238979b8b6..8d839b79fb 100644 >> --- a/linux-user/elfload.c >> +++ b/linux-user/elfload.c >> @@ -2334,7 +2334,7 @@ static uintptr_t pgb_find_hole(uintptr_t guest_loaddr, >> uintptr_t guest_size, >> /* Record the lowest successful match. */ >> if (ret < 0) { >> - ret = align_start - guest_loaddr; >> + ret = align_start; >> } >> /* If this hole contains the identity map, select it. */ >> if (align_start <= guest_loaddr && >> > > It seems not consistent with what we have with fallback where we substract > the guest_loadaddr: > > 2289 if (!maps) { > 2290 ret = pgd_find_hole_fallback(guest_size, brk, align, offset); > 2291 return ret == -1 ? -1 : ret - guest_loaddr; > 2292 } Hmm yeah. I can just make that a straight: return pgd_find_hole_fallback(guest_size, brk, align, offset); > > Thanks, > Laurent -- Alex Bennée
