From owner-freebsd-arm@FreeBSD.ORG Mon Apr 6 19:53:46 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 C3B602B8 for ; Mon, 6 Apr 2015 19:53:46 +0000 (UTC) Received: from orange.myspectrum.nl (unknown [IPv6:2a01:7c8:aab2:19e:5054:ff:fe1e:7dad]) by mx1.freebsd.org (Postfix) with ESMTP id 846BDBA7 for ; Mon, 6 Apr 2015 19:53:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id 27E638CC4B; Mon, 6 Apr 2015 21:53:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdYS3egVOOas; Mon, 6 Apr 2015 21:53:37 +0200 (CEST) Received: from [192.168.178.11] (5ED6B7F1.cm-7-7c.dynamic.ziggo.nl [94.214.183.241]) (Authenticated sender: freebsd_arm@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id 934BF8CC4A; Mon, 6 Apr 2015 21:53:37 +0200 (CEST) Message-ID: <5522E440.3010306@myspectrum.nl> Date: Mon, 06 Apr 2015 21:53:36 +0200 From: Jeroen Hofstee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Olivier Houchard , Rui Paulo Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S References: <20150405015245.GO51048@funkthat.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <3427080.JV46itjP9L@akita> <20150406194007.GA64433@ci0.org> In-Reply-To: <20150406194007.GA64433@ci0.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 19:53:47 -0000 Hi, On 06-04-15 21:40, Olivier Houchard wrote: > 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. For what it is worth, a similar issue is discussed at https://sourceware.org/bugzilla/show_bug.cgi?id=12518 Regards, Jeroen