From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:15:43 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD9CD820 for ; Mon, 6 Apr 2015 22:15:43 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A09EAE1C for ; Mon, 6 Apr 2015 22:15:43 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so493949igb.1 for ; Mon, 06 Apr 2015 15:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=w3pwr59V5H/xpFzpsbb6BG0Ljxkt2xVVDs4WF00aIHY=; b=Eprzbfl1nAZE3LyvfIB5J2qm54nqzobgzIjmWflHW9ebbGLys6HPEnE5D5zAKlTIP0 VSsZbgn28ASFAksoSXxJT5YtfVLkQJmVdYJJbQkxVzmRhejPD8uSB5juT2W0uly+g+TA xMfN7wyT3Q7/o7g16vXtRKhKeaIJ2izfPZRMzCfsOfeaEKqw+ZXqlMtRbbYKhMKWCUre 81ek9kz3zRsPt3GvsaSQ6ISlh+ooyishckwvBnRCWGpZd0S9PrP/5M5wz5xdR9XKR+/m 9hm5ob7ISLpkn+RT9DJPdiWqPJU9tl8+eFL8M2HFsd08UezzUOmK/ux9/nAQPmD+NWUt Kwbg== X-Gm-Message-State: ALoCoQmapV0NMkcJStDFHBQdzIyu0lyaU+v5T+5hqZlB+FLbRKAM55IB9TAps0Idil4lR67vMPFC X-Received: by 10.107.131.135 with SMTP id n7mr8696910ioi.37.1428358542535; Mon, 06 Apr 2015 15:15:42 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id b6sm3562463igb.15.2015.04.06.15.15.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 15:15:41 -0700 (PDT) Sender: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_066E2555-DA65-4BDF-8594-4917AB521E3A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <1428341561.82583.154.camel@freebsd.org> Date: Mon, 6 Apr 2015 16:15:40 -0600 Message-Id: References: <20150405015245.GO51048@funkthat.com> <1428341561.82583.154.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 22:15:44 -0000 --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 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 = 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 >>> #include >>>=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--