remove broken lib/libc/arm/string/memcpy_xscale.S

[John-Mark Gurney]

Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 19:41 +0200:
> On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote:
> > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600:
> > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> > > > 
> > > > I would like to remove this file as it does not implement our defined
> > > > memcpy.  Per POSIX, overlapping regions passed to memcpy is undefined
> > > > behavior.  We have defined it to have the same symatics as memmove.
> > > > 
> > > > Sample test program:
> > > > #include <stdio.h>
> > > > #include <string.h>
> > > > 
> > > > char bufa[512] = "this is a test buffer that should be copied fine.";
> > > > int
> > > > main()
> > > > {
> > > > 
> > > >        memcpy(&bufa[10], &bufa[0], strlen(&bufa[10]));
> > > >        printf("%s\n", bufa);
> > > > 
> > > >        return 0;
> > > > }
> > > > 
> > > > Output on amd64 HEAD:
> > > > this is a this is a test buffer that should be co
> > > > 
> > > > Output on old armv4 from 9.x:
> > > > this is a this is a thst buffethst bufhould beufh
> > > > 
> > > > If you just look at the file, it is clear that the implementation does
> > > > not adjust the copy direction based upon pointers.  We imported the
> > > > code from NetBSD, and NetBSD does apparently require memcpy's arguments
> > > > to be non-overlapping.
> > > > 
> > > > I'll remove the file shortly unless someone can prove to me that all
> > > > uses of memcpy in our tree do not depend upon our defined behavior
> > > > per memcpy(3)'s man page.
> > > 
> > > Any chance you can fix this implementation instead?
> > 
> > I don't know arm assembly well enough, nor do I have the time to fix
> > it.. I am willing to test any implementations as I have access to
> > hardware...
> > 
> > I guess I should add a test to verify that memcpy behavese like memmove
> > to our test suite...
> > 
> 
> I think the bug is in the manpage, not the code, and we should fix it the way
> NetBSD did.

Have you audited all of our code base to confirm that such a change
will not break anything?  The man page has been like this since r1573,
so it's very possible that code has been written to depend upon this
behavior...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."