Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 8, 2019 at 9:39 PM Aurelien Jarno <aurelien@aurel32.net> wrote:
> We are at a point were we should probably look for a real solution
> instead of relying on tricks.
*sigh* i _have_ been pointing out for several years now that this is
a situation that is going to get increasingly worse and worse, leaving
perfectly good hardware only fit for landfill.
i spoke to Dr Stallman about the lack of progress here:
https://sourceware.org/bugzilla/show_bug.cgi?id=22831
he expressed some puzzlement as the original binutils algorithm was
perfectly well capable of handling linking with far less resident
memory than was available at the time - and did *NOT*, just like gcc -
assume that virtual memory was "the way to go". this because the
algorithm used in ld was written at a time when virtual memory was far
from adequate.
then somewhere in the mid-90s, someone went "4GB is enough for
anybody" and ripped the design to shreds, making the deeply flawed and
short-sighted assumption that application linking would remain -
forever - below 640k^H^H^H^H4GB.
now we're paying the price.
the binutils-gold algorithm (with options listed in the bugreport, a
is *supposed* to fix this, however the ld-torture test that i created
shows that the binutils-gold algorithm is *also* flawed: it probably
uses mmap when it is in *no way* supposed to.
binutils with the --no-keep-memory option actually does far better
than binutils-gold... in most circumstances. however it also
spuriously fails with inexplicable errors.
basically, somebody needs to actually properly take responsibility
for this and get it fixed. the pressure will then be off: linking
will take longer *but at least it will complete*.
i've written the ld-torture program - a random function generator -
so that it can be used to easily generate large numbers of massive c
source files that will hit well over the 4GB limit at link time. so
it's easily reproducible.
l.
p.s. no, going into virtual memory is not acceptable. the
cross-referencing instantly creates a swap-thrash scenario, that will
put all and any builds into 10 to 100x the completion time. any link
that goes into "thrash" will take 2-3 days to complete instead of an
hour. "--no-keep-memory" is supposed to fix that, but it is *NOT* an
option on binutils-gold, it is *ONLY* available on the *original*
binutils-ld.
Reply to: