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

[Warner Losh]

> On Apr 6, 2015, at 11:32 AM, Ian Lepore <ian at freebsd.org> wrote:
> 
> 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.

I just looked at what NetBSD has. I’ve looked at the assembly here.
I think that we should just use the generic implementation now. These routines
are optimized for xscale, and don’t seem to be that much better than the
generic routines.

So as long as you don’t break arm, armeb, armv6, etc it should be OK.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20150406/6cf88471/attachment.sig>