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

Hi Aurelien,

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):

- There would need to be a team of '32-bit porters' (probably
   overlapping with the porters for the remaining 32-bit architectures)
   who manage the changes to make and keep this working. Without a team
   committed to this, we can't really support this in a stable release.

- There would need to be a rough consensus that the solution is the way
   to go.

- The solution needs to work on the buildds. We still want all binaries
   to be built on the buildds.

- 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.

- It's not our intention to lower the bar for architectures in testing.
   On the contrary. We intend to raise the bar at some point. As we
   already stated in the past, we would really prefer if more release
   architectures had some type of automated testing (piuparts,
   autopkgtests, archive rebuilds, etc). Eventually, this will probably
   become a requirement for release architectures.

- For architectures to be included in a future stable release, they
   still need to be in good enough shape. I won't go into everything
   involved in architecture qualification in this mail, but I do want to
   mention that the buildd capacity for mipsel/mips64el is quite limited.
   During the buster release cycle, they had trouble keeping up. If this
   continues, we might be forced to drop (one of) these architectures in
   the near future.

>     In the past it would have been enough to "just" do that for GCC, but
>     nowadays, it will also be needed for rustc, clang and many more. The
>     clang case is interesting as it is already a cross-compiler
>     supporting all the architectures, but it default to the native
>     target. I wonder if we should make mandatory the "-target" option,
>     just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
>     Alternatively instead of creating new packages, we might just want
>     to use the corresponding multiarch 64-bit package and use a wrapper
>     to change the native target, ie passing -m32 to gcc or -target to
>     clang.

I think a solution based on multiarch packages would probably be nicer 
than the mess of having packages for the 32-bit arch that contain the 
64-bit compiler.

Thanks,

Ivo