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

[Aurelien Jarno <aurelien@aurel32.net>]

On 2019-08-09 16:26, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker <ivodd@debian.org> wrote:
> >
> > 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.
> 
> it was a long time ago: people who've explained it to me sounded like
> they knew what they were talking about when it comes to insisting that
> builds be native.
> 
> fixing binutils to bring back the linker algorithms that were
> short-sightedly destroyed "because they're so historic and laughably
> archaic why would we ever need them" should be the first and only
> absolute top priority.
> 
> only if that catastrophically fails should other options be considered.
> 
> with the repro ld-torture code-generator that i wrote, and the amount
> of expertise there is within the debian community, it would not
> surprise me at all if binutils-ld could be properly fixed extremely
> rapidly.
> 
> a proper fix would also have the advantage of keeping linkers for
> *other* platforms (even 64 bit ones) out of swap-thrashing, saving
> power consumption for build hardware and costing a lot less on SSD and
> HDD regular replacements.

That would only fix ld, which is only a small part of the issue. Do you
also have ideas about how to fix llvm, gcc or rustc which are also
affected by virtual memory exhaustion on 32-bit architectures?

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net