From owner-freebsd-arm@FreeBSD.ORG Fri Jan 19 00:04:49 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE5F516A415 for ; Fri, 19 Jan 2007 00:04:49 +0000 (UTC) (envelope-from nick@flirble.org) Received: from plum.flirble.org (plum.flirble.org [195.40.6.20]) by mx1.freebsd.org (Postfix) with ESMTP id B62DC13C45E for ; Fri, 19 Jan 2007 00:04:49 +0000 (UTC) (envelope-from nick@flirble.org) Received: from nick by plum.flirble.org with local (Exim 4.43) id 1H7gzz-000Keu-By; Thu, 18 Jan 2007 23:48:51 +0000 Date: Thu, 18 Jan 2007 23:48:51 +0000 From: Nicholas Clark To: ticso@cicely.de Message-ID: <20070118234851.GL5748@plum.flirble.org> Mail-Followup-To: ticso@cicely.de, Olivier Houchard , Bernd Walter , freebsd-arm@freebsd.org References: <20070111101528.GV80390@cicely12.cicely.de> <20070118191823.GB42638@ci0.org> <20070118200931.GD9200@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070118200931.GD9200@cicely12.cicely.de> User-Agent: Mutt/1.3.25i X-Organisation: Tetrachloromethane Sender: Nicholas Clark Cc: Bernd Walter , freebsd-arm@freebsd.org Subject: Re: memcpy limitation X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 00:04:50 -0000 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