Bug#887993: ioquake3: FTBFS on x32: assumes __x86_64__ is LP64

[Simon McVittie]

Source: ioquake3
Version: 1.36+svn2287-1
Severity: wishlist
Tags: help upstream
User: debian-x32 at lists.debian.org
Usertags: port-x32

ioquake3 defines the feature-test macro "idx64" if the compiler predefined
macro __x86_64__ is defined, or "id386" if the platform is i386. The x32
ILP32 ABI is neither of these, leading to broken assumptions in various
places (notably the x86 JIT in vm_x86.c, where a pointer is assumed to
be 64 bits long if idx64 is defined).

idx64 represents the normal x86_64 LP64 ABI, so it is not correct for
this to be defined on x32. id386 represents the i386 ABI, so that is
not correct for x32 either.

If someone wants to port and test ioquake3 on x32, a minimal port would
probably be to treat x32 (defined(__x86_64__) && !defined(__LP64__)) as
neither id386 nor idx64, resulting in the same non-optimized code paths
being used as for e.g. arm64, ia64 or mips (pure interpreter rather than
a JIT, no optimized assembler versions of functions, etc.). I suspect
this would work fine.

For a full port at the same level as i386 and x86_64, each special case
for id386 or idx64 would need to be checked to work out whether this is
a way in which x32 is more like i386 (ILP32 data model) or more like
x86_64 (modern FPU with SSE, legacy i387 instructions best avoided),
probably via a new idx32 macro representing the x32 ABI. This might be
a waste of effort, because modern x86_64 CPUs are so much faster than
the 1999 CPUs that this engine was designed for anyway.

Either of these changes, if done, should happen upstream first:
https://github.com/ioquake/ioq3

I do not intend to work on either of these myself. x32 users can use the
amd64 binary until/unless x32 porting happens.

    smcv