From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:25:30 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 AB795AE5 for ; Mon, 6 Apr 2015 22:25:30 +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 EF045F0C for ; Mon, 6 Apr 2015 22:25:29 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 14034120FAF; Mon, 6 Apr 2015 22:00:33 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 06 Apr 2015 22:00:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428357633282:526239237 X-MC-Ingress-Time: 1428357633281 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp1.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YfF4K-0001JR-R1; Mon, 06 Apr 2015 22:00:32 +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 t36M0Upg073483; Mon, 6 Apr 2015 16:00:31 -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/SoCjAHFE5OrP4EDT4RsFG Message-ID: <1428357630.82583.157.camel@freebsd.org> Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S From: Ian Lepore To: John-Mark Gurney Date: Mon, 06 Apr 2015 16:00:30 -0600 In-Reply-To: <20150406215156.GZ51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> <20150406215156.GZ51048@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, Rui Paulo 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:25:30 -0000 On Mon, 2015-04-06 at 14:51 -0700, John-Mark Gurney wrote: > Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 21:40 +0200: > > On Mon, Apr 06, 2015 at 11:32:25AM -0700, Rui Paulo wrote: > > > On Monday 06 April 2015 19:41:30 Olivier Houchard wrote: > > > > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote: > > > > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600: > > > > > > > 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? > > > > > > > > > > I don't know arm assembly well enough, nor do I have the time to fix > > > > > it.. I am willing to test any implementations as I have access to > > > > > hardware... > > > > > > > > > > I guess I should add a test to verify that memcpy behavese like memmove > > > > > to our test suite... > > > > > > > > I think the bug is in the manpage, not the code, and we should fix it the > > > > way NetBSD did. > > > > > > Our implementation of memcpy() allows strings to overlap, so we really > > > shouldn't be special-casing armv4. > > > > Any use of memcpy() with overlapping strings is a bug, I fail to see why we > > should make any effort to make it work. > > Are you willing to do the work to make amd64/i386 and other platforms > behave incorrectly (one way or the other) when they overlap? If you > aren't willing to do that (and fix the resulting bugs), how do you > expect me to deal w/ unfound bugs in armv4 that depend upon this > "buggy" behavior? > As Olivier pointed out on irc, this isn't actually xscale code, it's used for all armv5+ systems. To me that says that there isn't a whole lot of existing code relying on the non-standard behavior because arm systems actually work. For non-arm systems, the potential breakage exists primarily in drivers and MD code that aren't used on arm, and that's a much smaller universe of potential breakage. -- Ian