Re: glibc 2.2.4 on the mpc860 cpu

[Axel Kittenberger]

> > sysdeps/powerpc/memset.S is broken! That was a bitch to find as my new
> > ld.so constantly crashed. I approximated the error with debug outputs in
> > ld.so. One cannot run ld.so in gdb(server), or can I? After searching on
> > the web afterwards it seems to be a well known problem, memset.S assumes
> > a 32 byte cache line, but the little mpc has just 16 bytes. Simple fix
> > was of course just to delete it. Don't know how this problem can be
> > cleanly solved, but I think resetting memory by using advantage of the
> > cash line is rendered unusable because the routine can't know how big it
> > is. Still the "normal" assembler memset might be quite faster than the
> > generic c one. Another possibilty would be to define a macro when
> > compiled with --with-cpu=860 to define the cache line to 16. (In the
> > archives the problem seems to be the same but the other way around as the
> > power3 cpu seems to have a 64 byte cacheline)
>
> There's unfortunatly no real solution for this yet.

Wouldn't it be safer to default disable memset.S before this is resolved? So 
those who know what they are doing can enable it. and those who don't are 
safed from the segfaults.

One possible idea, the instruction to the determine the cache line size is 
unfortunally on the ppc a kernel mode instruction, so you can't use it in 
user space, right? Now what happens if you still try to execute it?  I guess 
a trap will be thrown, now isn't it possible for the kernel to fill in the 
data just as if the instruction was successful and return contral to the 
userspace? This would safe from adding a new sys call. Unfortunally I guess I 
don't have really time to spent on ntis case, since thinking economically the 
advantage of having an advanced memset aganst the needed dev time doesn't 
seem to pay out. :(

>
> > I've configured glibc with the prefix=/usr as this is the destination on
> > the target. However for the cross-compiler I installed it otherwhere by
> > specifing a installroot like /usr/local/cross (of course, since I want to
> > keep my glibc for the x86 on my host machine :o))
> > However the created file /usr/local/cross/usr/lib/libc.so contains a link
> > to /lib/libc.so.6 beeing the libc of my host not the target. Since the
>
> Since you gave prefix, it uses that prefix.  installroot is for
> installing it somewhere else and then moving it around or packaging
> it.

So for cross compiler support the suggested way is to install two times? Once 
with the prefix as the target sees it issued with an installroot (for later 
copyng the libs to the target) and once for the cross compiler in it's path 
to access the libs and headers?