Re: [Valgrind-developers] mmap strangeness on ppc32-linux

[Julian S. <js...@ac...>]

>         Paul Mackerras <pa...@sa...> wrote:
>
> >> This strikes me as strange because the addresses (0xFFFDE000 etc) are
> >> almost at the end of 4G.  It's also strange because other programs,
> >> including large ones, run just fine, and these .so's are mapped quite
> >> low, as is normal.
> >
> > It looks like those libraries have been prelinked on a 64-bit system
> > and then moved to a 32-bit system.  32-bit processes get more address
> > space (4GB) on a 64-bit machine than an a 32-bit machine (where they
> > get either 2GB or 3GB).
> >
> > However, I would expect the dynamic linker to recover from the mmap
> > failure and just retry by mapping the library somewhere else.

Paul, Tom, thanks for the analysis.  With that info the problem is obvious.

V's address space manager has a clear idea of what address ranges it 
doesn't want the client to use, but it doesn't have a clear idea of what
ranges the kernel might refuse.

ld.so asks for a hinted mapping at 0xFFFDE000, aspacemgr says "ok by me",
ML_(generic_PRE_sys_mmap) duly presents that to the kernel, but now as
MAP_FIXED, and the kernel refuses.  So the syscall wrapper for mmap hands
the failure back to ld.so.

My fix is: in ML_(generic_PRE_sys_mmap), if the kernel refuses what was
originally a hinted mapping, try again as a non-hinted mapping.  That
appears to fix the problem.

J