Date: Mon, 06 Apr 2015 11:32:41 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <1428341561.82583.154.camel@freebsd.org> In-Reply-To: <EBEF298E-38F7-49BA-8BFC-D8B61C0F0BBA@bsdimp.com> References: <20150405015245.GO51048@funkthat.com> <EBEF298E-38F7-49BA-8BFC-D8B61C0F0BBA@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2015-04-06 at 09:58 -0600, Warner Losh wrote:
> > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney <jmg@funkthat.com> 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 <stdio.h>
> > #include <string.h>
> >
> > 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.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1428341561.82583.154.camel>