From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 06:42:20 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B3A8106566B; Wed, 18 Feb 2009 06:42:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAB38FC14; Wed, 18 Feb 2009 06:42:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1I6g84X042155; Tue, 17 Feb 2009 23:42:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 23:42:16 -0700 (MST) Message-Id: <20090217.234216.1276682135.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips 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: Wed, 18 Feb 2009 06:42:21 -0000 In message: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> Marcel Moolenaar writes: : : On Feb 17, 2009, at 9:21 PM, M. Warner Losh wrote: : : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/ : > bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required : > alignment of target type : > : : > : there's still 3 or 4 of these in the tree that I'm trying to track : > : back to root cause. A simple (void *) fixes the problem, but I want : > : to understand the issues before I slap that bad-boy in there... : > : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : Normally on 32-bit architectures, 64-bit data types have a 32-bit : alignment requirement by virtue of needing 2 32-bit loads/stores : to read/write them. Does 32-bit MIPS use 64-bit wide registers? MIPS isn't normal :). MIPS really is a 64-bit architecture. The only way to make the warning go away would be to build -mmips32r2 or something like that. But since we're going to be supporting n32 ABI (which really is a 64-bit ABI despite its name) and n64, the issue won't be going away. This is desirable for the Octeon support that I hope to commit soon. : > One way to fix this is to add __aligned(8) to struct rt_msghdr to : > compensate for this. Otherwise, if the time_t element is referenced : > in ifm_data we'll core dump. : : A safer approach is to mark ifi_epoch as packed or put differently, : define time_t as a 64-bit integral with 32-bit alignment. This can : avoid a lot of unexpected internal padding as well (e.g. struct : timeval). Marking it as packed won't help. If the elements aren't properly aligned, gcc won't access multi-word entities properly. It might eliminate the warning, but it will break at runtime. Warner