From owner-freebsd-arm@FreeBSD.ORG Wed Feb 17 17:17:48 2010 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BEC01065670 for ; Wed, 17 Feb 2010 17:17:48 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 12F4C8FC0A for ; Wed, 17 Feb 2010 17:17:47 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 7E0E7C427D; Wed, 17 Feb 2010 18:19:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id J0QnKgIFfBDD; Wed, 17 Feb 2010 18:19:39 +0100 (CET) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id B3AA0C41E7; Wed, 17 Feb 2010 18:19:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20100217.100004.321689434032786752.imp@bsdimp.com> Date: Wed, 17 Feb 2010 18:17:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100217151607.GU43625@cicely7.cicely.de> <20100217151941.GV43625@cicely7.cicely.de> <20100217152900.GX43625@cicely7.cicely.de> <20100217.100004.321689434032786752.imp@bsdimp.com> To: "M. Warner Losh" X-Mailer: Apple Mail (2.1077) Cc: rpaulo@gmail.com, freebsd-arm@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: kdump on ARM 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: Wed, 17 Feb 2010 17:17:48 -0000 On 2010-02-17, at 18:00, M. Warner Losh wrote: > In message: <20100217152900.GX43625@cicely7.cicely.de> > Bernd Walter writes: > : On Wed, Feb 17, 2010 at 04:19:41PM +0100, Bernd Walter wrote: > : > On Wed, Feb 17, 2010 at 04:16:07PM +0100, Bernd Walter wrote: > : > > On Wed, Feb 17, 2010 at 02:54:05PM +0000, Rui Paulo wrote: > : > > > On 17 Feb 2010, at 14:18, Grzegorz Bernacki wrote: > : > > > I wonder if this can't be made non arm conditional? > : >=20 > : > Ups - I'd just recovered from Mr. Sandman's work. > : > So we all agree about. > : > Nevertheless it should be verified if this is just a faulty struct > : > definition. > : > On the other hand I think it is not because someone else wrote it = is > : > a brokem on mips as well. > :=20 > : I'm really still sleeping - noone mentioned mips at all. > : > > Either this struct is properly aligned or not. > : > > So why should this be made conditional? > : > > Non strict alignment architecturs also have problems with this, = but > : > > it is usualy just speed penalties. > : > > There is one ARM sepcific struct missalignment problem. > : > > In this case we usually add __packed macro to structure = definition. > : > > For most structures this usually means no change on other > : > > archtitectures and we only declare the struct to forcibly be = what the > : > > programmer already expected. > : > > Only a few programmers are aware that they expect something from > : > > structures, which is not garantied. >=20 > This code is clearly nutso when it comes to alignment. I've come up > with a slightly better patch. I'd though about doing the structure > assignment that I suggested in a prior note, but the compiler is free > to assume alignment when copying the structures, which may end badly. > There's no way we can add __packed or __aligned easily to this code > (although the ktrstat and ktrsockaddr routines should be able to have > that annotation, a quick test suggests that the annotations I tried > didn't take right). >=20 > I don't have a good ARM setup at the moment to actually test these > changes. Can others test them? They seem to work for me on x86, but > that isn't saying much. Thanks, this looks better. We'll test this in our set-up and verify, but = only tomorrow I guess... Rafal