Marc Espie <[email protected]> wrote:
> Not surprisingly, a lot of software that claims to be 64 bits-ready isn't.
> This touches all web navigators, most jit engines, and probably lots more
> of software (our ports tree version of gnu-grep, for instance).
I don't think a lot suffers from it, but some prominent cases do.
Three problems have been mentioned:
(1) Truncation of pointers to 32 bits. Our malloc(3) has returned
addresses >4 GB for some time now on amd64 (and before that on
other archs like alpha), so I don't expect any new fallout
there. I seem to remember that we had a rash of ports fixes
back when this first happened on amd64.
(2) Tagged pointers. A tagged pointer is when you "know" that not
all the bits in a pointer are used to generate an address and
you squeeze some other data into the "spare" bits. This blocks
newer versions of Firefox on sparc64. Mozilla's new JavaScript
engine uses tagged pointers and those "unused" address bits on
x86 are actually used on sparc64.
(3) The expectation that, no matter what their absolute address, the
relative offsets between all your pieces of data fit into 32
bits, i.e., all data is within a 4 GB window. That sounds like
a bizarre requirement, but apparently some JIT engines are
"optimized" to rely on this. These are the cases that break
with new vmmap.
But, hey, 64-bit desktop machines have only been around since 1993
or so, and I guess some of the Mozilla programmers weren't born yet
when we watched oh-so-clever tagged pointer use blow up at, say,
the Motorola 68000 to 68020 transition some 25 years ago.
--
Christian "naddy" Weisgerber [email protected]
