From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 22:24:09 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 7312AA8E; Mon, 6 Apr 2015 22:24:09 +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 4D1C8F03; Mon, 6 Apr 2015 22:24:09 +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 t36MO7nE010684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2015 15:24:07 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t36MO7Ln010683; Mon, 6 Apr 2015 15:24:07 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Apr 2015 15:24:07 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406222407.GB51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <1428341561.82583.154.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 15:24:07 -0700 (PDT) Cc: freebsd-arm@FreeBSD.org, Ian Lepore 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:24:09 -0000 Warner Losh wrote this message on Mon, Apr 06, 2015 at 16:15 -0600: > > > On Apr 6, 2015, at 11:32 AM, Ian Lepore wrote: > > > > 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. > > I just looked at what NetBSD has. I???ve looked at the assembly here. > I think that we should just use the generic implementation now. These routines > are optimized for xscale, and don???t seem to be that much better than the > generic routines. I've looked and I don't see a version of memmove.S in NetBSD... There is lib/libc/arch/arm/string/bcopy.S which includes memmove.S, but I can't find memmove.S in their tree... It could be a generated file as I don't know their build infrastructure... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."