From owner-freebsd-arm@FreeBSD.ORG Fri Jan 25 11:23:18 2008 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 3348516A41A for ; Fri, 25 Jan 2008 11:23:18 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E937513C459 for ; Fri, 25 Jan 2008 11:23:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 95CD42084; Fri, 25 Jan 2008 12:23:09 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 813072082; Fri, 25 Jan 2008 12:23:09 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 5D483844B6; Fri, 25 Jan 2008 12:23:09 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Willem Jan Withagen References: <479880A7.1030107@digiware.nl> <20080124.084828.1608359032.imp@bsdimp.com> <864pd386mj.fsf@ds4.des.no> <20080124.110954.179240992.imp@bsdimp.com> <47991E08.6070609@digiware.nl> <20080125041540.GA30262@zibbi.meraka.csir.co.za> <4799A2B3.4060003@digiware.nl> Date: Fri, 25 Jan 2008 12:23:09 +0100 In-Reply-To: <4799A2B3.4060003@digiware.nl> (Willem Jan Withagen's message of "Fri\, 25 Jan 2008 09\:49\:55 +0100") Message-ID: <86prvq5eua.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org Subject: Re: sshd broken 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: Fri, 25 Jan 2008 11:23:18 -0000 Willem Jan Withagen writes: > John Hay wrote: >>>> The problem is that the char array isn't guaranteed to be aligned in >>>> any way. The fix posted is correct. >>>> >>>> There may be other fixes too, such as using a union to force >>>> alignment. >>> Well I'm sort of puzzled right now since after preprocessing the >>> variable allocation part boils down to: >>> =3D=3D=3D=3D=3D >>> struct msghdr msg; >>> struct iovec vec; >>> char ch =3D '\0'; >>> ssize_t n; >>> >>> char tmp[((((unsigned)(sizeof(struct cmsghdr)) + (sizeof(int) - >>> 1)) & ~(sizeof(int) - 1)) + (((unsigned)(sizeof(int)) + (sizeof(int >>> ) - 1)) & ~(sizeof(int) - 1)))]; >>> struct cmsghdr *cmsg; >>> =3D=3D=3D=3D=3D >>> So as far as I can see is char tmp[] included between 2 4-byte >>> items and allocation should be "automagically" 4-byte aligned. >>> >>> Now adding simple code like tmp[0] =3D 50, the first part of the >>> assembly is: (Comments are mine for as far as I can grasp them) >> >> Just doing tmp[0] =3D 50 will cause a byte access which should not be a >> problem. The original code does something like this (simplified): >> >> char tmp[CMSG_SPACE(sizeof(int))]; >> int *ti; >> >> ti =3D tmp; >> *ti =3D 50; >> >> Now the 50 is an int and not a byte and then the alignment does matter. > > I know, But to figure out where the array temp is allocated on the > stack the easiest to do that is to assign a value to its first > element. In assembly you will then find that the starting address that > the compiler has calculated for this array. > [...] None of this matters. What John pointed out means that the code is wrong and the compiler is right. The code is not allowed to assume that an object is correctly aligned unless it is of a type that requires the correct alignment. The easiest way to do this is with a union, e.g. union { char space[CMSG_SPACE(sizeof(int)); int value; } tmp; tmp.value =3D 50; A trickier way to do it is with a struct: struct { int value; char pad[CMSG_SPACE(sizeof(int)) - sizeof(int)]; } tmp; tmp.value =3D 50; in both cases, you are guaranteed that 1) tmp is be large enough (though possibly larger than required) 2) tmp is correctly aligned and 3) (void *)&tmp =3D=3D (void *)&tmp.value. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no