6 messages in org.freebsd.freebsd-armmemcpy limitation| From | Sent On | Attachments |
|---|---|---|
| Bernd Walter | Jan 11, 2007 2:15 am | |
| Olivier Houchard | Jan 18, 2007 7:07 pm | |
| Bernd Walter | Jan 18, 2007 8:09 pm | |
| Olivier Houchard | Jan 18, 2007 8:44 pm | |
| Nicholas Clark | Jan 19, 2007 12:04 am | |
| Bernd Walter | Jan 19, 2007 12:35 am |
| Subject: | memcpy limitation | |
|---|---|---|
| From: | Nicholas Clark (ni...@ccl4.org) | |
| Date: | Jan 19, 2007 12:04:30 am | |
| List: | org.freebsd.freebsd-arm | |
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)
Nicholas Clark