Date: Thu, 18 Jan 2007 21:55:02 +0100 From: Olivier Houchard <mlfbsd@ci0.org> To: ticso@cicely.de Cc: Bernd Walter <ticso@cicely12.cicely.de>, freebsd-arm@freebsd.org Subject: Re: memcpy limitation Message-ID: <20070118205502.GA45272@ci0.org> In-Reply-To: <20070118200931.GD9200@cicely12.cicely.de> References: <20070111101528.GV80390@cicely12.cicely.de> <20070118191823.GB42638@ci0.org> <20070118200931.GD9200@cicely12.cicely.de>
index | next in thread | previous in thread | raw e-mail
On Thu, Jan 18, 2007 at 09:09:31PM +0100, Bernd Walter wrote:
> On Thu, Jan 18, 2007 at 08:18:23PM +0100, Olivier Houchard wrote:
> > On Thu, Jan 11, 2007 at 11:15:28AM +0100, Bernd Walter wrote:
> > > I get a sigbus with the following:
> > > #0 0x00033158 in $a () at lcp.c:939
> > > 939 memcpy(&req, opt, sizeof req);
> > > (gdb) print req
> > > $1 = {hdr = {id = 0 '\0', len = 0 '\0'}, proto = 0, period = 0}
> > > (gdb) print &req
> > > $2 = (struct lqrreq *) 0xbfffe4a0
> > > (gdb) print opt
> > > $3 = (struct fsm_opt *) 0xbfffe5b6
> > >
> > > Shouldn't memcpy work with any alignment?
> > >
> >
> > It certainly does. Would you have a simple test case which reproduce this ?
> > Or does it happen as soon as you try to do an unaligned copy ?
> > I'm quite confused on why it would happen, memcpy is shared between the kernel
> > and the userland, and in kernel I'm sure it does unaligned copies.
>
> It's a while back, but I remember from looking at the dissassembly that
> it had nothing in common with our assembly function.
> I thought this is a compiler internal.
> Will try to do a small test case.
> As a workaround I exchange the memcpy call with a bcopy.
>
So that probably won't be our implementation, because our bcopy just calls
memcpy if the two strings do not overlap (and it doesn't seem to be your case).
Olivier
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070118205502.GA45272>