From owner-freebsd-arm@freebsd.org Wed Feb 15 16:25:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6591ACE06E1 for ; Wed, 15 Feb 2017 16:25:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 313E79F5 for ; Wed, 15 Feb 2017 16:25:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id 203so67788383ith.0 for ; Wed, 15 Feb 2017 08:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1p2V26ixNf+f0+MgBWNnKwvhd27eAm6DGmt0phNxaJU=; b=EjgFn5LHSD6kEtUouAIf1xVR0PBa/hdrJxbYIXbxrTgRNrO3xcEC/WxfGLI6naXQ02 fB+QwYE2I0OXuFgvXJBZI27HNSpaVwr/MYqWBTdAwky3auLvkci6+NVBztSYf95FAIjj SNirYWwuJs+5+TTMtPuPE6hbFADGZB0B5Lr7sN69JPTXHICYEVXr5CCz6UJpYTD4vGm7 dj1zuUu9gVPbw1QQEduWNgduZFIaHM5TmWJwWGIqf8TjJv1/AVZX6s0/Q3GxRTyyQspC zNcktd2ApV7wooUsTdEz5F6Q8LhSH96kpnpog6l586fGVu4JLtBt1watVFNGYteBzda+ 7n/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1p2V26ixNf+f0+MgBWNnKwvhd27eAm6DGmt0phNxaJU=; b=Xr5/nBi3jPV4NglrLpY9SIE4H8CdToAcXTUu6HtTG0D8QiJgX73IU9MnL20mU3ize1 ZzhdHurWP9tjflEhezp96vjA+BMJPC98JxQtCYq0AA61E6ieRJTr2Yc/ZeZS9JaQet3z UR56ts0mZxq5SpmkwVa/DDBi0N3N4W1NPcgaMBSKt0fN1Sp0jPSkZdkhHjz8KN9zrzIa tNiQs9Pq1qwYbRYZ3x0NXC+5L1Uc4pPEdWA8Jss8ALF1bJM+mSMxzy4j3zw1AtzgNBQg kjPtcawmz2PnaBGJ8QUjXb8xehkEfhGYB8w0uvK6nVkuBpKssLM8TqqZbs51O0jm7h4h 4kMA== X-Gm-Message-State: AMke39lZg4ztKFdz5O5TxD0m8E/BEsXayqf39r7VOsBcNVAyKpgjKaIu6r/lIml3CnQh3YJLZqZc90EaFTCrYQ== X-Received: by 10.107.198.195 with SMTP id w186mr32799609iof.19.1487175910319; Wed, 15 Feb 2017 08:25:10 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Wed, 15 Feb 2017 08:25:09 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> References: <5335118.oK1KXXDaG5@pc-alex> <25360EAB-3079-4037-9FB5-B7781ED40FA6@dsl-only.net> <7424243.zp5tqGREgJ@pc-alex> <8E5F8A15-2F79-4015-B93B-975D27308782@dsl-only.net> <674C2DA0-808D-4968-B86D-7CADEC3A7EEE@dsl-only.net> From: Warner Losh Date: Wed, 15 Feb 2017 09:25:09 -0700 X-Google-Sender-Auth: 2TEGSgpMRVp4eI8WOyM9KQRfEoA Message-ID: Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] To: Mark Millard Cc: Alexandre Martins , freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:25:11 -0000 On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard wrote: > On 2017-Feb-13, at 1:27 AM, Mark Millard wrote: > >> As the decision about when to call the code that can >> deal with overlapping memory regions is wrong, the code >> that should only be used for non-overlaping regions likely >> would handle some overlapping regions and so would operate >> incorrectly in at least some cases. >> >> In other words, I think the bug is worse than just an >> example of being sub-optimal: the code is wrong from what >> I can tell. (I've no clue if the code is ever put to use >> for any bad cases.) > > I was wrong about the error status, possibly for multiple reasons, > but the following is sufficient: > > https://www.freebsd.org/cgi/man.cgi?query=memcpy&sektion=3 > > says: > > In this implementation memcpy() is implemented using bcopy(3), and there- > fore the strings may overlap. On other systems, copying overlapping > strings may produce surprises. Programs intended to be portable should > use memmove(3) when src and dst may overlap. > > so the branch taken case for: > > bcc PIC_SYM(_C_LABEL(memcpy), PLT) > > also deals with overlaps since FreeBSD criteria is > that memcpy does so. (I had been thinking that it > did not deal with such.) > > > Side note: > > Notably the arm implementation of FreeBSD memcpy does not call > bcopy (that would be recursive in the arm implementation). > memcpy just needs to have some properties that bcopy also has. > > This suggests that memcpy vs. bcopy may have a performance > Principle of Least Astonishment violation since memcpy may well > perform differently than bcopy for some types of contexts but > memcpy is supposed to use bcopy. > > > [A varient of these notes are in the comments for bugzilla > 217065.] Seems like the memcpy man page should be softened to reflect the !x86 reality. If we provide different semantics between different arches, we should consider carefully why and document in the code or change. Warner