----- Original message -----
From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
To: Florian Weimer <fweimer@xxxxxxxxxx>, "Michal Suchánek" <msuchanek@xxxxxxx>
Cc: linux-mm@xxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, Nick Piggin <npiggin@xxxxxxxxxxx>, Anton Blanchard <anton@xxxxxxxxxxx>
Subject: Re: PIE binaries are no longer mapped below 4 GiB on ppc64le
Date: Thu, Nov 1, 2018 8:24 AM
On Wed, 2018-10-31 at 18:54 +0100, Florian Weimer wrote:
>
> It would matter to C code which returns the address of a global variable
> in the main program through and (implicit) int return value.
>
> The old behavior hid some pointer truncation issues.
Hiding bugs like that is never a good idea..
> > Maybe it would be good idea to generate 64bit relocations on 64bit
> > targets?
>
> Yes, the Go toolchain definitely needs fixing for PIE. I don't dispute
> that.
There was never any ABI guarantee that programs would be loaded below
4G... it just *happened*, so that's not per-se an ABI change.
That said, I'm surprised of the choice of address.. I would have rather
moved to above 1TB to benefit from 1T segments...
Nick, Anton, do you know anything about that change ?
Looks like Michael found the offending commit.
I guess there is precedent for avoiding address space expansion as a compatibility concern, with the 128TB limit. That's pretty horrible though. I would have much rather added some new limits or a new system call even that could be used to control virtual address space allocation behaviour without all these ad hoc mmap flags and implicit changes to behaviour with different combinations of parameters to mmap(2). Anyway I digress.
I was looking at the first 1T segments issue a while ago. I *think* we might be able to use a 1T segment for address 0 by default, and then hit it with a hammer and go back to 256MB if the app does something interesting like a fixed 4k mapping or hugetlbfs mapping.
Thanks,
Nick
