On Wed, 2003-11-12 at 22:27, David S. Miller wrote: > On Wed, 12 Nov 2003 19:06:17 -0800 > "David S. Miller" <[email protected]> wrote: > > > The statfs64 etc. structure layouts are defined in files in the > > glibc sources, somewhere under sysdeps/unix/sysv/linux/sparc/* > > > > That's where you need to see if what's found there differs from > > what the Sparc kernel headers actully use for sparc32 and sparc64. > > Not a glibc bug, I just realized that the strace dump given > in this thread was for a 32-bit process and the 'sz' argument > of 0x58 is indeed correct for a 32-bit process. > > The 2.6.x kernel bug, which I posted a patch for earlier in this > thread, is the solution to this statfs64 syscall problem. > > There was another issue wrt. sparc64, that hello world programs > don't even work, is it related? Indeed, it even fails for me: > > ./hello: error while loading shared libraries: /lib64/libc.so.6: unexpected > reloc type 0x08 > > Maybe this could be related to the binutils issue that Meelis Roos > said prevents current debian unstable's binutils from building 2.6.x > kernels properly? > > Actually, it seems that a R_SPARC_WDISP22 case needs to be added to > the switch statement in GLIBC's: > > sysdeps/sparc/sparc64/dl-machine.h:elf_machine_rela() > > That ought to fix this problem, something like: > > case R_SPARC_WDISP22: > *(unsigned int *) reloc_addr = > ((*(unsigned int *)reloc_addr & ~0x3fffff) | > (((value - (Elf64_Addr) reloc_addr) >> 2) > & 0x3fffff)); > break; > > should work just fine. >
Would this be a problem for sparcv9 optimized libraries? Jim
