Date: Wed, 15 Feb 2017 08:34:00 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail] Message-ID: <201702151634.v1FGY0Mx018911@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CANCZdfrbih-1FtTAy5P=W=tRU2ztwjt36hazHrEaEs_ygMRMKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard <markmi@dsl-only.net> wrote: > > On 2017-Feb-13, at 1:27 AM, Mark Millard <markmi at dsl-only.net> 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. We should consider that we never do that, please, that is just asking for a lot of foot shooting! Especially with something as fundemental as memcpy/bcopy! -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201702151634.v1FGY0Mx018911>