Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Apr 2015 15:24:07 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-arm@FreeBSD.org, Ian Lepore <ian@FreeBSD.org>
Subject:   Re: remove broken lib/libc/arm/string/memcpy_xscale.S
Message-ID:  <20150406222407.GB51048@funkthat.com>
In-Reply-To: <BA53E900-AA5D-4007-B1F8-C2A0075BC816@bsdimp.com>
References:  <20150405015245.GO51048@funkthat.com> <EBEF298E-38F7-49BA-8BFC-D8B61C0F0BBA@bsdimp.com> <1428341561.82583.154.camel@freebsd.org> <BA53E900-AA5D-4007-B1F8-C2A0075BC816@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 16:15 -0600:
> 
> > On Apr 6, 2015, at 11:32 AM, Ian Lepore <ian@freebsd.org> wrote:
> > 
> > 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.
> 
> I just looked at what NetBSD has. I???ve looked at the assembly here.
> I think that we should just use the generic implementation now. These routines
> are optimized for xscale, and don???t seem to be that much better than the
> generic routines.

I've looked and I don't see a version of memmove.S in NetBSD...  There is
lib/libc/arch/arm/string/bcopy.S which includes memmove.S, but I can't
find memmove.S in their tree...  It could be a generated file as I don't 
know their build infrastructure...

-- 
  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?20150406222407.GB51048>