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

[Warner Losh]

> On Apr 6, 2015, at 4:24 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
> 
> Warner Losh wrote this message on Mon, Apr 06, 2015 at 16:15 -0600:
>> 
>>> 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.
> 
> I've looked and I don't see a version of memmove.S in NetBSD...  There is
> lib/libc/arch/arm/string/bcopy.S which includes memmove.S, but I can't
> find memmove.S in their tree...  It could be a generated file as I don't
> know their build infrastructure...

bcopy is memmove with a different arg order, so they do assembler tricks to
provide both interfaces.

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/865dd4ff/attachment.sig>