Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On Fri, Aug 09, 2019 at 02:31:47PM +0200, Ivo De Decker wrote:
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> 
> > 32-bit processes are able to address at maximum 4GB of memory (2^32),
> > and often less (2 or 3GB) due to architectural or kernel limitations.
> 
> [...]
> 
> Thanks for bringing this up.
> 
> > 1) Build a 64-bit compiler targeting the 32-bit corresponding
> >     architecture and install it in the 32-bit chroot with the other
> >     64-bit dependencies. This is still a kind of cross-compiler, but the
> >     rest of the build is unchanged and the testsuite can be run. I guess
> >     it *might* be something acceptable. release-team, could you please
> >     confirm?
> 
> As you noted, our current policy doesn't allow that. However, we could
> certainly consider reevaluating this part of the policy if there is a
> workable solution.
> 
> Some random notes (these are just my preliminary thoughts, not a new release
> team policy):
[...]
> - We are talking about having both native 32-bit and 64-bit packages in
>   the same environment. We are NOT talking about emulated builds. The
>   resulting (32-bit) binaries still need to run natively in the build
>   environment.

Hello,

this requirement poses a significant difficulty: while 64bit x86
CPUs can always execute 32bit x86 code, the same isn't
necessarily the case on other architectures. On arm, there is no
requirement that an arm64 system has to be able to execute 32bit
arm code and in particular in the arm server space, i.e. on the
kind of hardware that DSA wants to have for running buildds on,
64bit-only systems are becoming more and more common. On RISC-V
the 64bit and 32bit ISAs have been disjunct forever, i.e. there
is no riscv64 system that can natively execute riscv32 code. I
don't know what the situation looks like in mips and ppc/power
land but I wouldn't be surprised if developments would go into
the same direction there.

Regards,
Karsten