Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
Ivo De Decker <[email protected]>
| Newsgroups | gmane.linux.debian.ports.mips,gmane.linux.debian.ports.arm,gmane.linux.debian.devel.general,gmane.linux.debian.devel.release |
|---|---|
| Message-ID | <[email protected]> |
Hi, 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 >> 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. 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. Ivo