Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Apr 2015 10:12:48 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: remove broken lib/libc/arm/string/memcpy_xscale.S
Message-ID:  <20150406171248.GV51048@funkthat.com>
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
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 <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?

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...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150406171248.GV51048>