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

Ian Lepore ian at freebsd.org
Mon Apr 6 20:55:02 UTC 2015


On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote:
> > 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?
> 
> Warner

I don't think we should be wasting our scarce developer resources trying
to redevelop high-performance string functions for long-obsolete arm
hardware.  Just revert to the generic implementations, and perhaps
someone who actually uses that old hardware will contribute high
performance implementations that follow the rules.

Hmmm, does netbsd have xscale performance implementations of memmove()?
Maybe we can just drop that in as memcpy().  Any more work than that is
probably wasted effort at this late date.

-- Ian




More information about the freebsd-arm mailing list