| 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: | Bernd Walter (tic...@cicely12.cicely.de) | |
| Date: | Jan 18, 2007 8:09:28 pm | |
| List: | org.freebsd.freebsd-arm | |
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.
-- B.Walter http://www.bwct.de http://www.fizon.de ber...@bwct.de in...@bwct.de supp...@fizon.de





