From owner-freebsd-current@FreeBSD.ORG Sun Nov 12 20:22:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C0B16A407; Sun, 12 Nov 2006 20:22:05 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B1B943DA8; Sun, 12 Nov 2006 20:21:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKLonu029896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:21:51 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4557825E.3070009@errno.com> Date: Sun, 12 Nov 2006 12:21:50 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: Ruslan Ermilov References: <20061112133929.9194773068@freebsd-current.sentex.ca> <20061112140010.GA47660@rambler-co.ru> <20061112144230.GC2331@kobe.laptop> <20061112145151.GC49703@rambler-co.ru> <20061112151150.GA2988@kobe.laptop> <20061112155723.GB50349@rambler-co.ru> <20061112165904.GP6501@plum.flirble.org> <20061112171436.GF50349@rambler-co.ru> <20061112180758.GD4237@kobe.laptop> <20061112132105.6bac38d6@kan.dnsalias.net> <20061112192810.GC1173@rambler-co.ru> In-Reply-To: <20061112192810.GC1173@rambler-co.ru> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, current@freebsd.org, Giorgos Keramidas Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:22:06 -0000 Ruslan Ermilov wrote: > 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. > > 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). This issue appears to have broken if_bridge. On my avila board I align rx packets to be aligned s.t. the ip header lands on a 32-bit boundary. This results in the ethernet header being 2-byte aligned which is ok on other platforms. But the compiler takes this code in bridge_forward: /* * If the interface is learning, and the source * address is valid and not multicast, record * the address. */ if ((bif->bif_flags & IFBIF_LEARNING) != 0 && ETHER_IS_MULTICAST(eh->ether_shost) == 0 && (eh->ether_shost[0] == 0 && eh->ether_shost[1] == 0 && eh->ether_shost[2] == 0 && eh->ether_shost[3] == 0 && eh->ether_shost[4] == 0 && eh->ether_shost[5] == 0) == 0) { (void) bridge_rtupdate(sc, eh->ether_shost, src_if, 0, IFBAF_DYNAMIC); } and converts the 6 byte compares to a 32-bit and 16-bit compare. Since the data is only 16-bit aligned the 32-bit load faults. So the point is that just because things compile doesn't necessarily mean they work. And worse code that works on many/most other architectures may not work. Sam