memcpy limitation

[Bernd Walter]

On Thu, Jan 18, 2007 at 11:48:51PM +0000, Nicholas Clark wrote:
> 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.
> 
> Does the memcpy() work if you cast both arguments to (void *) ?
> 
> I've got this niggling feeling that if (at least) one is an aligned pointer
> type the compiler feels able to substitute a fast, word aligned-routine.
> 
> In my run-ins with compilers in these sort of issues, they usually know the
> C standard better than I do, so it that solves it, it's probably the compiler
> that is right. (In particular, do not argue with xlc on AIX or the SGI
> compiler on 64 bit IRIX)

Sounds reasonable.
Will check about this.
But it will have to wait a few days.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de