[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


On 8/9/19 4:41 PM, Karsten Merker wrote:
On Fri, Aug 09, 2019 at 02:31:47PM +0200, Ivo De Decker wrote:
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


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.

To be clear:

This requirement would only apply for 32-bit ports that are built with 64-bit compilers. For ports that are built natively (as happens now) nothing would change.

So if (say) armhf would be built using 64-bit (arm64) compilers, the build environment for armhf would need to be able to run both the 64-bit and 32-bit binaries natively.

For 64-bit architectures that are built natively (like arm64), there is no requirement that these buildds should be able to run 32-bit binaries.

If (some of) the arm64 buildds would run on hardware that doesn't support 32-bit, that would obviously mean that builds for armel and armhf would have to be done on other hardware.

And for 32-bit architectures that are built natively, there is no requirement that the buildds should be able to run 64-bit binaries (assuming building on 32-bit still works).

I hope this clarifies what I meant.


Reply to: