From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 21:52:07 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 5C8D132B for ; Mon, 6 Apr 2015 21:52:07 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 373A6BFF for ; Mon, 6 Apr 2015 21:52:06 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t36LpvLJ010274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 14:51:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36LpuIm010273; Mon, 6 Apr 2015 14:51:56 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 14:51:56 -0700 From: John-Mark Gurney To: Olivier Houchard Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406215156.GZ51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150406194007.GA64433@ci0.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 06 Apr 2015 14:51:57 -0700 (PDT) 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 21:52:07 -0000 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? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."