Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
---
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.
l.
Reply to: