[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64bits & df



On Wed, 2003-11-12 at 22:27, David S. Miller wrote:
> On Wed, 12 Nov 2003 19:06:17 -0800
> "David S. Miller" <davem@redhat.com> 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




Reply to: