From owner-freebsd-arm@FreeBSD.ORG Sun Nov 12 22:48:43 2006 Return-Path: X-Original-To: arm@FreeBSD.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B055B16A4A0; Sun, 12 Nov 2006 22:48:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B640D43D5E; Sun, 12 Nov 2006 22:48:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kACMkwDG081266; Sun, 12 Nov 2006 15:46:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 12 Nov 2006 15:47:33 -0700 (MST) Message-Id: <20061112.154733.-432839119.imp@bsdimp.com> To: ru@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20061112192810.GC1173@rambler-co.ru> References: <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 12 Nov 2006 15:46:58 -0700 (MST) Cc: arm@FreeBSD.org, current@FreeBSD.org, kabaev@gmail.com, keramida@FreeBSD.org Subject: Re: [head tinderbox] failure on arm/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: Sun, 12 Nov 2006 22:48:43 -0000 In message: <20061112192810.GC1173@rambler-co.ru> Ruslan Ermilov writes: : On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote: : > GCC expects 4-byte aligned structured on ARM but does not necessarily : > have to. We can change the default at the expense of possible more : > inefficient code generated and lost binary compatibility with other ARM : > OSes out there. So this is trade off between unclear performance : > penalty and an unspecified but certainly sizable number of other : > landmines like this lurking on the code. : > : > We should decide what evil we regard as lesser. : > : This is the only buildworld problem so far on FreeBSD/ARM, so my : feeling is that we can actually benefit from leaving it "as is", : as it has a potential of making our code more portable. Of course : if binary compatibility for structs across platforms is an issue, : a structure should be "packed", because otherwise the C standard : says that "Each non-bit-field member of a structure or union object : is aligned in an implementation-defined manner appropriate to its : type." : : On the other hand, having GCC align "struct foo { char x[11]; }" : on a four-byte boundary (other than for backward compatibility) : doesn't make too much sense to me. It does for me. People shouldn't think of structs as being packed. The standard is very clear about the allowed type punning and the disallowed. Many platforms pad structures to the size of a word, and we have to cope. In this specific case, it should be __packed__ because the structure is intended to be packed. : I don't know GCC rules for alignment of structure members. For : example, if it's guaranteed (in GCC) that offsetof(struct foo, bar) : is always 1 for "struct foo { char foo; char bar; }" (without the : "packed" attribute) on all platforms and OSes GCC supports? : I'd expect the latter to be "4" for FreeBSD/ARM but fortunately : it stays "1", i.e., only the structure alignment is affected, : and not of structure members (which is POLA but makes the 4 byte : for structure alignment questionable). It is all up to the compiler. Trying to figure it out is not possible. There's no POLA to violate, unless you expect the whole world to behave like a i386 :-). Warner