Calling fstat() in a C program compiled for sparc32 will eventually lead to the 'fstat64' syscall being made - as observed with 'strace'. However, when compiled with -m64, strace shows that the inferior 'fstat' syscall is executed, thereby giving a zero nanosecond part.
Created attachment 4505 [details] test case Compile this with -m64. You should observe: 1260745109.876573675 1260745109.000000000 When compiled with -static, objdump prints (for -m32): 0001d720 <fstat64>: 1d720: 94 10 00 09 mov %o1, %o2 1d724: 92 10 00 08 mov %o0, %o1 1d728: 90 10 20 03 mov 3, %o0 1d72c: 82 13 c0 00 mov %o7, %g1 1d730: 10 80 00 0c b 1d760 <___fxstat64> While with -m64: 000000000010d9c0 <fstat64>: 10d9c0: 94 10 00 09 mov %o1, %o2 10d9c4: 92 10 00 08 mov %o0, %o1 10d9c8: 90 10 20 03 mov 3, %o0 10d9cc: 82 13 c0 00 mov %o7, %g1 10d9d0: 10 68 00 0c b %xcc, 10da00 <__fxstat> So __fxstat64 is not called in 64-bit mode. This looks like a glibc bug to me.
This trivial patch fixes it. Index: glibc-2.10.1/sysdeps/unix/sysv/linux/sparc/sparc64/fxstat.c =================================================================== --- glibc-2.10.1.orig/sysdeps/unix/sysv/linux/sparc/sparc64/fxstat.c +++ glibc-2.10.1/sysdeps/unix/sysv/linux/sparc/sparc64/fxstat.c @@ -1 +1 @@ -#include "../../fxstat.c" +#include "../../i386/fxstat.c"
So is this ever going to be fixed?
I plan to check this fix in, just as soon as I can get a successful sparc64 build of the current tree. It currently crashes when running the rpc programs.
Fix committed to mainline.