Comment 29 for bug 750585

just saw Steve's earlier comment, apparently the logic to pick the right unistd_32.h or unistd_64.h was added after that, so this is Fix Released, not Invalid.

There's now asm/unistd_x32.h as well. AFAICT from poking around in the kernel source, uname -m should return x86_64 when called from a x86_x32 uname binary. I don't see anything mucking with utsname()->machine, outside of what I think is just the ia32 handling, not used for x86_x32 userspace (since they still run in long mode, with 64 bit registers. They just choose not to use addresses that don't fit in 32bits.)

 So x86_x32 userspace won't ever get their own unistd.h processed, but it's minimally different from unistd_64.h, and has to be that way for the kernel support to be as minimally invasive as it is. The extra names that unistd_x32.h has that unistd_64.h doesn't is probably not relevant unless you're trying to debug the glibc wrappers around the calls that need help, I hope.

 You *could* use cpp to get the right unistd.h, but you couldn't just cpp /usr/include/unistd.h, because that would substitute the __NR_callname macros that the script is looking for.