Date: Mon, 6 Apr 2015 16:15:40 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <BA53E900-AA5D-4007-B1F8-C2A0075BC816@bsdimp.com> In-Reply-To: <1428341561.82583.154.camel@freebsd.org> References: <20150405015245.GO51048@funkthat.com> <EBEF298E-38F7-49BA-8BFC-D8B61C0F0BBA@bsdimp.com> <1428341561.82583.154.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On Apr 6, 2015, at 11:32 AM, Ian Lepore <ian@freebsd.org> wrote:
>=20
> On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote:
>>> On Apr 4, 2015, at 7:52 PM, John-Mark Gurney <jmg@funkthat.com> =
wrote:
>>>=20
>>> 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.
>>>=20
>>> Sample test program:
>>> #include <stdio.h>
>>> #include <string.h>
>>>=20
>>> char bufa[512] =3D "this is a test buffer that should be copied =
fine.";
>>> int
>>> main()
>>> {
>>>=20
>>> memcpy(&bufa[10], &bufa[0], strlen(&bufa[10]));
>>> printf("%s\n", bufa);
>>>=20
>>> return 0;
>>> }
>>>=20
>>> Output on amd64 HEAD:
>>> this is a this is a test buffer that should be co
>>>=20
>>> Output on old armv4 from 9.x:
>>> this is a this is a thst buffethst bufhould beufh
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> Any chance you can fix this implementation instead?
>>=20
>> Warner
>=20
> 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.
>=20
> 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=E2=80=99ve looked at the assembly =
here.
I think that we should just use the generic implementation now. These =
routines
are optimized for xscale, and don=E2=80=99t seem to be that much better =
than the
generic routines.
So as long as you don=E2=80=99t break arm, armeb, armv6, etc it should =
be OK.
Warner
--Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVIwWMAAoJEGwc0Sh9sBEAzBIP/2ZStS0buY9asslWCGyJsa4P
PCWM/8W1wXxR6KZDWu9qjzhMPOTY+kNtxN7EZ9SST7gzQJTBJ7d8aAuDaNlo7/k8
Vyf9PiYcH5yU6F+aDsxIzEa0a/d36dB1xToXwyCIPrOnz1qnXrvfROitnlXadbcs
eLk4hRjcD0/9YcosZ/vfXET8WKlxPufBvtqD/KnHo5q47IgNFnZRruXg6NN4N2gh
rrAu16iPYzpyEsun8UoM7kHE+ZSxs0PTRHfV/gJ2Kr0JG7R2HO+pR0IBc0brS+pA
/oJxD4TIacEznBsp8ZqtZsfOQ5DI5wiSV30CPiGqasO7R1XUrejw/WAlMovWy7/V
1F22IYCDCBBGXxJGG7x4Qb+xkA0fiMWTC79Tpi8e8g+rLEQ8rZxgD9/gWos84Mb6
UfpaE0qaUYUFvZCZkw0UCm6iGD9+xCtMnGsQQBuuNbAN9MWgVlmJ0hk+Q86BtwBO
+uZXz81OFCghmjd0Fb8JzPRpGX3NX3mW/DaSKRr9Jxvrp8+fcqa/kG/5gNraqcsF
x636gR4Z+eknsAloWVsrxQtGceElwrqvv84XCpXVDvdqtZ2qBm6vt/5Hvteb3o7O
BWJMKfxRxPKSLTWlLp63X1rn9Eas8wMYfB268OWQzNMBgeC4KvMrX+dwGnuaEOr1
66hws9oN1CjcpFfXB3/Z
=rnAd
-----END PGP SIGNATURE-----
--Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BA53E900-AA5D-4007-B1F8-C2A0075BC816>