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: | Olivier Houchard (mlf...@ci0.org) | |
| Date: | Jan 18, 2007 8:44:18 pm | |
| 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.
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