From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:32:34 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 9CA5FC3 for ; Mon, 6 Apr 2015 19:32:34 +0000 (UTC) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtpout002.mac.com [17.172.81.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC7F993 for ; Mon, 6 Apr 2015 19:32:33 +0000 (UTC) Received: from akita.localnet (209-23-203-214-Illinois.hfc.comcastbusiness.net [209.23.203.214]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NME00BN7E618530@st11p00mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Mon, 06 Apr 2015 18:32:27 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-06_04:2015-04-06,2015-04-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504060172 From: Rui Paulo To: freebsd-arm@freebsd.org Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Date: Mon, 06 Apr 2015 11:32:25 -0700 Message-id: <3427080.JV46itjP9L@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <20150406174130.GA63423@ci0.org> References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii 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 19:32:34 -0000 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. -- Rui Paulo