From owner-freebsd-arm@FreeBSD.ORG Fri Jan 25 08:50:05 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 0E45C16A418 for ; Fri, 25 Jan 2008 08:50:05 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id B46CE13C469 for ; Fri, 25 Jan 2008 08:50:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 68AE6171C6; Fri, 25 Jan 2008 09:50:03 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgNeBj+xni7o; Fri, 25 Jan 2008 09:49:57 +0100 (CET) Received: from [212.61.27.67] (opteron.digiware.nl [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id A56F117219; Fri, 25 Jan 2008 09:49:57 +0100 (CET) Message-ID: <4799A2B3.4060003@digiware.nl> Date: Fri, 25 Jan 2008 09:49:55 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Hay 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> In-Reply-To: <20080125041540.GA30262@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: des@des.no, 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 08:50:05 -0000 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: >> ===== >> struct msghdr msg; >> struct iovec vec; >> char ch = '\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; >> ===== >> 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] = 50, the first part of the assembly >> is: (Comments are mine for as far as I can grasp them) > > Just doing tmp[0] = 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 = tmp; > *ti = 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. And as far as I can tell [ fp, #-80 ] is going to be quad-aligned assuming that the framepointer is also quad-aligned. Now the not optimised version is that 50 is first loaded into r3, then moved into r2. And only then r2 is moved into memory. Whereas is would be allowed to skip the 'mov r2, r3' step, and do it directly from r3. You'd have to dump you erroneous code into asm, an have a look at what it generated. the gcc switch for that is -S and it leaves a .s file. Also do this for the case that works, and see the differences. Which is not going to be easy. Because by the time -O2 optimizing gets going, the code becomes rather obfuscated. I'm still trying to find an option that puts the source code and/or linenumbers in the asm code. I seem to remember that there used to be such a beast. But the gcc man-pages never stops.... --WjW