From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 20:55:02 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FAE4EC1 for ; Mon, 6 Apr 2015 20:55:02 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0A9346 for ; Mon, 6 Apr 2015 20:55:00 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 8A3A160F68; Mon, 6 Apr 2015 20:54:52 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp7.ore.mailhop.org (smtp7.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 06 Apr 2015 20:54:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428353692640:2752545603 X-MC-Ingress-Time: 1428353692640 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp7.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YfAtB-0003bj-Ng; Mon, 06 Apr 2015 17:32:45 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t36HWffA073047; Mon, 6 Apr 2015 11:32:41 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+g8oduF14rWM9FglNwQDfj Message-ID: <1428341561.82583.154.camel@freebsd.org> Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S From: Ian Lepore To: Warner Losh Date: Mon, 06 Apr 2015 11:32:41 -0600 In-Reply-To: References: <20150405015245.GO51048@funkthat.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie 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 20:55:02 -0000 On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote: > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney 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 > > #include > > > > 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