From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 03:03:04 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC6DB106564A for ; Wed, 18 Feb 2009 03:03:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A3EED8FC0C for ; Wed, 18 Feb 2009 03:03:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I2XSBS058210; Tue, 17 Feb 2009 21:33:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I2XS4o060522; Tue, 17 Feb 2009 21:33:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 227617302F; Tue, 17 Feb 2009 21:33:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218023328.227617302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 21:33:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:03:05 -0000 TB --- 2009-02-18 01:17:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 01:17:56 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips/mips TB --- 2009-02-18 01:17:56 - cleaning the object tree TB --- 2009-02-18 01:17:56 - cvsupping the source tree TB --- 2009-02-18 01:17:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 01:32:55 - building world TB --- 2009-02-18 01:32:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 01:32:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 01:32:55 - TARGET=mips TB --- 2009-02-18 01:32:55 - TARGET_ARCH=mips TB --- 2009-02-18 01:32:55 - TZ=UTC TB --- 2009-02-18 01:32:55 - __MAKE_CONF=/dev/null TB --- 2009-02-18 01:32:55 - cd /src TB --- 2009-02-18 01:32:55 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 01:32:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 02:33:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 02:33:27 - ERROR: failed to build world TB --- 2009-02-18 02:33:27 - 2896.77 user 337.68 system 4531.49 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 03:39:41 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9842B106564A; Wed, 18 Feb 2009 03:39:41 +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 4029C8FC18; Wed, 18 Feb 2009 03:39:41 +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 n1I3adYk040226; Tue, 17 Feb 2009 20:36:39 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 20:36:47 -0700 (MST) Message-Id: <20090217.203647.-1518647466.imp@bsdimp.com> To: tinderbox@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090218023328.227617302F@freebsd-current.sentex.ca> References: <20090218023328.227617302F@freebsd-current.sentex.ca> 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, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:39:42 -0000 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... Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 05:06:09 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 318AF106566C; Wed, 18 Feb 2009 05:06:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8398FC12; Wed, 18 Feb 2009 05:06:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF8006M6U28MG80@asmtp022.mac.com>; Tue, 17 Feb 2009 20:06:09 -0800 (PST) Message-id: <302F9BB0-AF38-422C-86DB-96FCF47C2168@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.203647.-1518647466.imp@bsdimp.com> Date: Tue, 17 Feb 2009 20:06:08 -0800 References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 05:06:09 -0000 On Feb 17, 2009, at 7:36 PM, M. Warner Losh wrote: > 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... I think the warning simply means that you cast from pointer to type A with alignment requirement P to pointer to type B with alignment requirement Q, and with P < Q. This doesn't necessary mean there's a problem (i.e that you have a misaligned dereference), but there's a potential. A case by case analysis is called for... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 05:24:48 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C471065670; Wed, 18 Feb 2009 05:24:48 +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 632558FC16; Wed, 18 Feb 2009 05:24:48 +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 n1I5LiA7041225; Tue, 17 Feb 2009 22:21:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 22:21:52 -0700 (MST) Message-Id: <20090217.222152.-109416210.imp@bsdimp.com> To: tinderbox@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090217.203647.-1518647466.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.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, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 05:24:49 -0000 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. 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. But that doesn't seem very portable and seems like a hack. Adding (void *) to "fix" the warning would be even worse... Anybody else have any ideas? Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 06:26:10 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A671C106564A; Wed, 18 Feb 2009 06:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8E88FC13; Wed, 18 Feb 2009 06:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF9003FQ0JKV900@asmtp017.mac.com>; Tue, 17 Feb 2009 22:26:10 -0800 (PST) Message-id: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.222152.-109416210.imp@bsdimp.com> Date: Tue, 17 Feb 2009 22:26:08 -0800 References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:26:11 -0000 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? > 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). Just a thought. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 06:42:20 2009 Return-Path: Delivered-To: mips@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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS 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 From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 06:51:12 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E381065676; Wed, 18 Feb 2009 06:51:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 30B858FC22; Wed, 18 Feb 2009 06:51:12 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF900CBA1PAMW60@asmtp015.mac.com>; Tue, 17 Feb 2009 22:51:12 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.234216.1276682135.imp@bsdimp.com> Date: Tue, 17 Feb 2009 22:51:10 -0800 References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:51:13 -0000 On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : 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. But GCC will use a pair of 32-bit loads and/or stores to access the 64-bit integral in that case. There should be no runtime breakage. You only do this for n32 of course. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 07:00:54 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F1D1065676; Wed, 18 Feb 2009 07:00:54 +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 541EB8FC1B; Wed, 18 Feb 2009 07:00:54 +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 n1I6wIkf042376; Tue, 17 Feb 2009 23:58:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 23:58:26 -0700 (MST) Message-Id: <20090217.235826.-1697751865.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:00:55 -0000 In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : : > : 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. : : But GCC will use a pair of 32-bit loads and/or stores to : access the 64-bit integral in that case. There should be : no runtime breakage. You only do this for n32 of course. Why only n32? Registers are still 64-bit in n32. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 12:49:16 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9447106566B; Wed, 18 Feb 2009 12:49:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE4B48FC16; Wed, 18 Feb 2009 12:49:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1ICnEUm003710; Wed, 18 Feb 2009 07:49:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1ICnEmS040353; Wed, 18 Feb 2009 07:49:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EF54F7302F; Wed, 18 Feb 2009 07:49:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218124913.EF54F7302F@freebsd-current.sentex.ca> Date: Wed, 18 Feb 2009 07:49:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 12:49:17 -0000 TB --- 2009-02-18 11:47:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 11:47:46 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 11:47:46 - cleaning the object tree TB --- 2009-02-18 11:47:57 - cvsupping the source tree TB --- 2009-02-18 11:47:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 11:48:05 - building world TB --- 2009-02-18 11:48:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 11:48:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 11:48:05 - TARGET=mips TB --- 2009-02-18 11:48:05 - TARGET_ARCH=mips TB --- 2009-02-18 11:48:05 - TZ=UTC TB --- 2009-02-18 11:48:05 - __MAKE_CONF=/dev/null TB --- 2009-02-18 11:48:05 - cd /src TB --- 2009-02-18 11:48:05 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 11:48:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 12:49:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 12:49:13 - ERROR: failed to build world TB --- 2009-02-18 12:49:13 - 2882.20 user 323.10 system 3687.23 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 14:14:05 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66BFD106564A for ; Wed, 18 Feb 2009 14:14:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) by mx1.freebsd.org (Postfix) with ESMTP id F1EA28FC0A for ; Wed, 18 Feb 2009 14:14:04 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20090218110413.ZPOG412.nschwmtas01p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Wed, 18 Feb 2009 11:04:13 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090218110412.OKRO7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 18 Feb 2009 11:04:12 +0000 Received: (qmail 13316 invoked by uid 501); 18 Feb 2009 11:04:02 -0000 Date: Wed, 18 Feb 2009 22:04:02 +1100 From: Andrew Reilly To: "M. Warner Losh" Message-ID: <20090218110402.GA13040@duncan.reilly.home> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090217.222152.-109416210.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.499BEB2D.0009,ss=1,fgs=0 Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:14:05 -0000 On Tue, Feb 17, 2009 at 10:21:52PM -0700, 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 > 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. If the memory that rtm can be pointing to can be either a struct rt_msghdr or a struct if_msghdr, then shouldn't it really be pointing to a union of those two, and then the alignment will sort itself out? (As far as I know, that's the only way that C99 will guarantee that the right thing happens anyway, otherwise strict aliasing analysis would allow much worse badness to happen, potentially.) Not looked at the code myself. Perhaps there's a reason why that would be unworkable. Cheers, Andrew From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 15:22:20 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C111065672; Wed, 18 Feb 2009 15:22: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 E81398FC23; Wed, 18 Feb 2009 15:22:19 +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 n1IFKsnu056598; Wed, 18 Feb 2009 08:20:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 08:21:03 -0700 (MST) Message-Id: <20090218.082103.-761055997.imp@bsdimp.com> To: andrew-freebsd@areilly.bpc-users.org From: "M. Warner Losh" In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> 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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:22:21 -0000 In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, 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 : > 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. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) This is a stream of data from the kernel, multiple messages, so making it be a union wouldn't force the proper alignment from the kernel... : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. Yes. There is. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 15:28:18 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EBD0106564A; Wed, 18 Feb 2009 15:28:18 +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 09D928FC12; Wed, 18 Feb 2009 15:28:17 +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 n1IFPoLM056703; Wed, 18 Feb 2009 08:25:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 08:25:59 -0700 (MST) Message-Id: <20090218.082559.-1112729020.imp@bsdimp.com> To: andrew-freebsd@areilly.bpc-users.org From: "M. Warner Losh" In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> 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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:28:19 -0000 In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, 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 : > 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. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) : : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. There's a second issue. There's a number of different structures that are type punned to rt_msghdr. I'm worried it would be an ABI change to do that as well. In this case, code inspection shows the code to be fine since the dangerous element isn't touched. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 18:19:36 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73F31065686; Wed, 18 Feb 2009 18:19:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id CF3138FC23; Wed, 18 Feb 2009 18:19:36 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from dpham-t61.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF9006SNXKNQS10@asmtp021.mac.com>; Wed, 18 Feb 2009 10:19:36 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.235826.-1697751865.imp@bsdimp.com> Date: Wed, 18 Feb 2009 10:19:34 -0800 References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:19:38 -0000 On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : > : > : 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. > : > : But GCC will use a pair of 32-bit loads and/or stores to > : access the 64-bit integral in that case. There should be > : no runtime breakage. You only do this for n32 of course. > > Why only n32? Registers are still 64-bit in n32. I think that's the problem. With registers still 64-bit, MIPS n32 isn't really behaving like a 32-bit machine in the case of 64-bit accesses. It's that aspect you want to tweak. So, if you give all 64-bit integrals an alignment of 4 bytes, then GCC will use a pair of 32-bit loads and stores (just like, say, powerpc) and you don't run into the alignment problems where all of a sudden a data structure gets 8-byte alignment, triggers warnings, and we try to correct it with kluges. For MIPS n64 things are like any other LP64 architecture, so you don't have to tweak anything. In other words: by tweaking the alignment of 64-bit types in n32, you prohibit GCC from using the 64-bit capabilities of the processor and MIPS isn't so weird anymore. NOTE: On ARM, GCC aligns structures to a 4-byte boundary by default. This has caused us problems and instead of fixing the default behaviour of the compiler, we slammed __packed onto structures. If we had changed the default behaviour of the compiler, then all structures would be naturally aligned and we would be able to use the half-word memory accesses that newer ARM processors have. No, we __packed the lot and created a big performance bottleneck because now we can only use byte-wise memory accesses. What was done for performance (default alignment of 4-bytes for structures), was turned into a huge pessimisation by us compensating with __packed. We have more optimal code if the compiler aligns structures on their natural boundary! The point being that programmers *do* code with certain assumptions and as soon as those assumptions don't hold on a platform, you end up worse off. My thoughts for MIPS n32 are to make it behave like any "normal" 32-bit strong- alignment platform to avoid 1) a large number of runtime alignment faults -- which are a bigger performance bottleneck than forcing 64-bit integrals to be accessed with 2 32-bit accesses and 2) avoid further abuse of __packed, which turns all accesses in a series of byte-wise accesses. At Juniper I changed the ARM compiler default by adding: -mstructure-size-boundary=8 That made life a *lot* simpler and performance hasn't been sacrificed. Just an explanation of where I'm coming from... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 19:07:19 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 011FB10656ED; Wed, 18 Feb 2009 19:07:19 +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 8671F8FC17; Wed, 18 Feb 2009 19:07:18 +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 n1IJ55rc059811; Wed, 18 Feb 2009 12:05:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 12:05:14 -0700 (MST) Message-Id: <20090218.120514.831271136.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20090217.235826.-1697751865.imp@bsdimp.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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:07:20 -0000 In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: : : > In message: : > Marcel Moolenaar writes: : > : : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : > : : > : > : 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. : > : : > : But GCC will use a pair of 32-bit loads and/or stores to : > : access the 64-bit integral in that case. There should be : > : no runtime breakage. You only do this for n32 of course. : > : > Why only n32? Registers are still 64-bit in n32. : : I think that's the problem. With registers still 64-bit, MIPS : n32 isn't really behaving like a 32-bit machine in the case of : 64-bit accesses. It's that aspect you want to tweak. So, if : you give all 64-bit integrals an alignment of 4 bytes, then : GCC will use a pair of 32-bit loads and stores (just like, : say, powerpc) and you don't run into the alignment problems : where all of a sudden a data structure gets 8-byte alignment, : triggers warnings, and we try to correct it with kluges. MIPS n32 is a 64-bit ABI in many ways, but 32-bit in others. Its data-types are 32-bit, but the compiler is free to leverage the underlying 64-bit machine to implement it. So for 64-bit quantities, is uses the ld/sd op codes. : For MIPS n64 things are like any other LP64 architecture, so : you don't have to tweak anything. I think so. : In other words: by tweaking the alignment of 64-bit types in : n32, you prohibit GCC from using the 64-bit capabilities of : the processor and MIPS isn't so weird anymore. I think so, but there's a twist. On MIPS, one kernel supports multiple ABIs at the same time. I'm not entirely sure how the routing interface would cope with this sort of thing because the size of u_long changes. I need to do some more research to see what's going on there... : NOTE: On ARM, GCC aligns structures to a 4-byte boundary by : default. This has caused us problems and instead of fixing : the default behaviour of the compiler, we slammed __packed : onto structures. If we had changed the default behaviour of : the compiler, then all structures would be naturally aligned : and we would be able to use the half-word memory accesses : that newer ARM processors have. No, we __packed the lot and : created a big performance bottleneck because now we can only : use byte-wise memory accesses. : What was done for performance (default alignment of 4-bytes : for structures), was turned into a huge pessimisation by us : compensating with __packed. We have more optimal code if : the compiler aligns structures on their natural boundary! The reason we have the compiler doing this on ARM is for ABI conformance. There are other ABIs on ARM that don't suffer from these problems. We should investigate using them. : The point being that programmers *do* code with certain : assumptions and as soon as those assumptions don't hold on : a platform, you end up worse off. My thoughts for MIPS n32 : are to make it behave like any "normal" 32-bit strong- : alignment platform to avoid 1) a large number of runtime : alignment faults -- which are a bigger performance bottleneck : than forcing 64-bit integrals to be accessed with 2 32-bit : accesses Run time faults aren't a bottleneck. They are a core dump, which is why I'm looking at this in the first place. :) : and 2) avoid further abuse of __packed, which turns : all accesses in a series of byte-wise accesses. We haven't really abused __packed. The items we have as '__packed' really are packed data structures for the wire. We have also added some __aligned() flag as well which help to mitigate the performance penalties because the compiler can unpack the items. : At Juniper I changed the ARM compiler default by adding: : -mstructure-size-boundary=8 : : That made life a *lot* simpler and performance hasn't been : sacrificed. Except you've invented a new ABI by doing that... I think that the project should look at transitioning to a different ABI that works better. ARM has several to choose from... : Just an explanation of where I'm coming from... Yes. Unfortunately, those kinds of hacks take us further away form the standard environment for these platforms. There are many dark corners of the current MIPS code that knows all the alignment and layout issues and changing the compiler to force a different alignment will break that code... Anyway, since we are a little ways away from having to cope with all the ABI issues for MIPS... It also turns out that in this case, a simple (void *) is safe and causes no issues because that time_t isn't accessed... It does give one time to pause and think about it. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 19:36:32 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C59F1065675; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 64CA58FC19; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from jflores-gxdt755.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFA00ME214TZA40@asmtp011.mac.com>; Wed, 18 Feb 2009 11:36:31 -0800 (PST) Message-id: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090218.120514.831271136.imp@bsdimp.com> Date: Wed, 18 Feb 2009 11:36:29 -0800 References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:36:33 -0000 On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: > : In other words: by tweaking the alignment of 64-bit types in > : n32, you prohibit GCC from using the 64-bit capabilities of > : the processor and MIPS isn't so weird anymore. > > I think so, but there's a twist. > > On MIPS, one kernel supports multiple ABIs at the same time. I'm not > entirely sure how the routing interface would cope with this sort of > thing because the size of u_long changes. I need to do some more > research to see what's going on there... Hmm... My first reaction is not to go there right away. It's probably safer or go the amd64 route: keep ILP32 and LP64 distinct. We have the infrastructure in place and we can always optimize and blend once things are working. > There are other ABIs on ARM that don't suffer from these problems. We > should investigate using them. I agree. It's better for FreeBSD/arm in particular if it's more like FreeBSD/i386. It may not be best for the ARM port in absolute sense, but we only have a few developers working on non-i386 hardware and a whole lot of developers who don't care about non-i386... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > > Run time faults aren't a bottleneck. They are a core dump, which is > why I'm looking at this in the first place. :) :-) > : At Juniper I changed the ARM compiler default by adding: > : -mstructure-size-boundary=8 > : > : That made life a *lot* simpler and performance hasn't been > : sacrificed. > > Except you've invented a new ABI by doing that... We have a products to make and a source base to work with. Swimming upstream is best left to salmons :-) > I think that the > project should look at transitioning to a different ABI that works > better. ARM has several to choose from... I tend to agree. > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. Fair enough. Misalignment in process space can easily be made non-fatal, in which case it's mostly a performance problem. That makes the problem space much more contained and therefore easier to deal with... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 20:45:22 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB9B10656D6; Wed, 18 Feb 2009 20:45:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B94CF8FC1A; Wed, 18 Feb 2009 20:45:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LZsaq-000Ne7-2O; Wed, 18 Feb 2009 22:00:28 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1IK0N4t065336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 22:00:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1IK0NrS094763; Wed, 18 Feb 2009 22:00:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1IK0NC4094762; Wed, 18 Feb 2009 22:00:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Feb 2009 22:00:23 +0200 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eNjIDde0W37E3OQP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LZsaq-000Ne7-2O 51d45eccd875aacf2d71f4555f4f2809 X-Terabit: YES Cc: mips@freebsd.org, tinderbox@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:45:23 -0000 --eNjIDde0W37E3OQP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2009 at 10:19:34AM -0800, Marcel Moolenaar wrote: >=20 > On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: >=20 > >In message: > > Marcel Moolenaar writes: > >: > >: On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > >: > >: > : A safer approach is to mark ifi_epoch as packed or put =20 > >differently, > >: > : define time_t as a 64-bit integral with 32-bit alignment. This =20 > >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. > >: > >: But GCC will use a pair of 32-bit loads and/or stores to > >: access the 64-bit integral in that case. There should be > >: no runtime breakage. You only do this for n32 of course. > > > >Why only n32? Registers are still 64-bit in n32. >=20 > I think that's the problem. With registers still 64-bit, MIPS > n32 isn't really behaving like a 32-bit machine in the case of > 64-bit accesses. It's that aspect you want to tweak. So, if > you give all 64-bit integrals an alignment of 4 bytes, then > GCC will use a pair of 32-bit loads and stores (just like, > say, powerpc) and you don't run into the alignment problems > where all of a sudden a data structure gets 8-byte alignment, > triggers warnings, and we try to correct it with kluges. >=20 > For MIPS n64 things are like any other LP64 architecture, so > you don't have to tweak anything. >=20 > In other words: by tweaking the alignment of 64-bit types in > n32, you prohibit GCC from using the 64-bit capabilities of > the processor and MIPS isn't so weird anymore. >=20 > NOTE: On ARM, GCC aligns structures to a 4-byte boundary by > default. This has caused us problems and instead of fixing > the default behaviour of the compiler, we slammed __packed > onto structures. If we had changed the default behaviour of > the compiler, then all structures would be naturally aligned > and we would be able to use the half-word memory accesses > that newer ARM processors have. No, we __packed the lot and > created a big performance bottleneck because now we can only > use byte-wise memory accesses. > What was done for performance (default alignment of 4-bytes > for structures), was turned into a huge pessimisation by us > compensating with __packed. We have more optimal code if > the compiler aligns structures on their natural boundary! >=20 > The point being that programmers *do* code with certain > assumptions and as soon as those assumptions don't hold on > a platform, you end up worse off. My thoughts for MIPS n32 > are to make it behave like any "normal" 32-bit strong- > alignment platform to avoid 1) a large number of runtime > alignment faults -- which are a bigger performance bottleneck > than forcing 64-bit integrals to be accessed with 2 32-bit > accesses and 2) avoid further abuse of __packed, which turns > all accesses in a series of byte-wise accesses. >=20 > At Juniper I changed the ARM compiler default by adding: > -mstructure-size-boundary=3D8 >=20 > That made life a *lot* simpler and performance hasn't been > sacrificed. >=20 > Just an explanation of where I'm coming from... I have a question. All architectures I had a slightest interest in, included the required alignment of types into the ABI specification. This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 and 2.0. Is MIPS different in this aspect ? --eNjIDde0W37E3OQP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmcaNYACgkQC3+MBN1Mb4iwHQCdEFcZiY7fFPfYKjvou23tkeng hWcAoI6GzgOthcWUAOzx09gY3wy6p/DL =x3VL -----END PGP SIGNATURE----- --eNjIDde0W37E3OQP-- From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:11:43 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0A32106566B; Wed, 18 Feb 2009 22:11:43 +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 E56FC8FC0A; Wed, 18 Feb 2009 22:11:42 +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 n1ILaTRJ061685; Wed, 18 Feb 2009 14:37:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 14:36:38 -0700 (MST) Message-Id: <20090218.143638.-1025539642.imp@bsdimp.com> To: kostikbel@gmail.com From: "M. Warner Losh" In-Reply-To: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> 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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:11:44 -0000 In message: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> Kostik Belousov writes: : I have a question. All architectures I had a slightest interest in, : included the required alignment of types into the ABI specification. : This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 : and 2.0. : : Is MIPS different in this aspect ? MIPS does define it as well. I have all the old o32 docs, but have had trouble locating the n32/n64 docs since they were done by SGI and SGI is now defunct. I know MIPS Technologies has information on nubi, which is yet another ABI family aimed more at the embedded platforms, but it hasn't had much traction. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:11:44 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1A7106566C; Wed, 18 Feb 2009 22:11:44 +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 DF47E8FC13; Wed, 18 Feb 2009 22:11:43 +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 n1ILXcel061679; Wed, 18 Feb 2009 14:34:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 14:33:47 -0700 (MST) Message-Id: <20090218.143347.466770936.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> References: <20090218.120514.831271136.imp@bsdimp.com> <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:11:44 -0000 In message: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> Marcel Moolenaar writes: : : On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: : > : In other words: by tweaking the alignment of 64-bit types in : > : n32, you prohibit GCC from using the 64-bit capabilities of : > : the processor and MIPS isn't so weird anymore. : > : > I think so, but there's a twist. : > : > On MIPS, one kernel supports multiple ABIs at the same time. I'm not : > entirely sure how the routing interface would cope with this sort of : > thing because the size of u_long changes. I need to do some more : > research to see what's going on there... : : Hmm... My first reaction is not to go there right away. It's : probably safer or go the amd64 route: keep ILP32 and LP64 : distinct. We have the infrastructure in place and we can : always optimize and blend once things are working. I don't think that's a viable option. MIPS doesn't have a 64-bit mode, but rather is always 64-bit. Or rather right now even in the port we have that supports n32 and n64 along side of o32, it is A or B or C. : > There are other ABIs on ARM that don't suffer from these problems. We : > should investigate using them. : : I agree. It's better for FreeBSD/arm in particular if it's : more like FreeBSD/i386. It may not be best for the ARM : port in absolute sense, but we only have a few developers : working on non-i386 hardware and a whole lot of developers : who don't care about non-i386... So far the number of places we've had to change in the kernel is minimal for the current ABI. The newer ABI is indeed targeted more at software that's been traditionally developed for x86 hardware. : > : At Juniper I changed the ARM compiler default by adding: : > : -mstructure-size-boundary=8 : > : : > : That made life a *lot* simpler and performance hasn't been : > : sacrificed. : > : > Except you've invented a new ABI by doing that... : : We have a products to make and a source base to work : with. Swimming upstream is best left to salmons :-) Yes. In a closed environment, you have that option. : > I think that the : > project should look at transitioning to a different ABI that works : > better. ARM has several to choose from... : : I tend to agree. : : : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : : Fair enough. Misalignment in process space can easily be : made non-fatal, in which case it's mostly a performance : problem. That makes the problem space much more contained : and therefore easier to deal with... Other systems on mips are a mixed bag. Some allow user land fixup, while others abort the application... I think we need more real-world experience for which one is the best approach... Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:12:50 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475971065679; Wed, 18 Feb 2009 22:12:50 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id F034B8FC34; Wed, 18 Feb 2009 22:12:48 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9996129B032; Wed, 18 Feb 2009 16:54:38 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Feb 2009 16:54:38 -0500 X-Sasl-enc: dXKtkqfSb1fnZTVFZkGS9ZcHDBV79PODrDElARWeQdY7 1234994078 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3446A1AD32; Wed, 18 Feb 2009 16:54:33 -0500 (EST) Message-ID: <499C8396.2020000@incunabulum.net> Date: Wed, 18 Feb 2009 21:54:30 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:12:50 -0000 M. Warner Losh wrote: > ... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > FWIW, Linux use a type-length-value protocol for the netlink routing socket, so alignment issues of this kind are shifted around (forgive the pun). > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. > Yes, the void * cast works around the issue for now, but doesn't offer any guarantees that we are doing the right thing on strict alignment architectures. If the alignment *is* invalid, then we take the hit. cheers BMS From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:45:59 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10E51065676; Wed, 18 Feb 2009 22:45:59 +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 6D7238FC1A; Wed, 18 Feb 2009 22:45:59 +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 n1IMi5Yb062162; Wed, 18 Feb 2009 15:44:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 15:44:14 -0700 (MST) Message-Id: <20090218.154414.-1283372409.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <499C8396.2020000@incunabulum.net> References: <20090218.120514.831271136.imp@bsdimp.com> <499C8396.2020000@incunabulum.net> 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-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:46:01 -0000 In message: <499C8396.2020000@incunabulum.net> Bruce Simpson writes: : M. Warner Losh wrote: : > ... : > : The point being that programmers *do* code with certain : > : assumptions and as soon as those assumptions don't hold on : > : a platform, you end up worse off. My thoughts for MIPS n32 : > : are to make it behave like any "normal" 32-bit strong- : > : alignment platform to avoid 1) a large number of runtime : > : alignment faults -- which are a bigger performance bottleneck : > : than forcing 64-bit integrals to be accessed with 2 32-bit : > : accesses : > : : FWIW, Linux use a type-length-value protocol for the netlink routing : socket, so alignment issues of this kind are shifted around (forgive the : pun). FreeBSD does too for the most part, but it is only at the inter-message level, not intra-message. : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : > : : Yes, the void * cast works around the issue for now, but doesn't offer : any guarantees that we are doing the right thing on strict alignment : architectures. : If the alignment *is* invalid, then we take the hit. Right. The compiler doesn't check it, but I just did and things are fine given the fields accessed. But its that last bit that's the problem... I also have changed the offending line in my tree to be u_long instead of time_t since that is a better match to the protocol, and also gives us 168 years of uptime before there's an issue. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:49:35 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9414106566B; Wed, 18 Feb 2009 22:49:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AEC228FC16; Wed, 18 Feb 2009 22:49:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1IMnXQW036221; Wed, 18 Feb 2009 17:49:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1IMnXnZ060359; Wed, 18 Feb 2009 17:49:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1A16A7302F; Wed, 18 Feb 2009 17:49:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218224933.1A16A7302F@freebsd-current.sentex.ca> Date: Wed, 18 Feb 2009 17:49:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:49:36 -0000 TB --- 2009-02-18 21:45:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 21:45:55 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 21:45:55 - cleaning the object tree TB --- 2009-02-18 21:46:17 - cvsupping the source tree TB --- 2009-02-18 21:46:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 21:46:27 - building world TB --- 2009-02-18 21:46:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 21:46:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 21:46:27 - TARGET=mips TB --- 2009-02-18 21:46:27 - TARGET_ARCH=mips TB --- 2009-02-18 21:46:27 - TZ=UTC TB --- 2009-02-18 21:46:27 - __MAKE_CONF=/dev/null TB --- 2009-02-18 21:46:27 - cd /src TB --- 2009-02-18 21:46:27 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 21:46:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr/yp_dbwrite.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv/yp_error.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_main.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c cc1: warnings being treated as errors /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c: In function 'yppasswdproc_update_master_1_svc': /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:823: warning: cast increases required alignment of target type /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:861: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/rpc.yppasswdd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 22:49:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 22:49:32 - ERROR: failed to build world TB --- 2009-02-18 22:49:32 - 2988.00 user 333.27 system 3817.88 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Feb 18 22:54:11 2009 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D084F1065670; Wed, 18 Feb 2009 22:54:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id B930D8FC12; Wed, 18 Feb 2009 22:54:11 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [172.24.240.93] (natint3.juniper.net [66.129.224.36]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFA0043BAA9QZ10@asmtp019.mac.com>; Wed, 18 Feb 2009 14:54:11 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090218.143638.-1025539642.imp@bsdimp.com> Date: Wed, 18 Feb 2009 14:54:09 -0800 References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: kostikbel@gmail.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:54:13 -0000 On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: > MIPS does define it as well. I have all the old o32 docs, but have > had trouble locating the n32/n64 docs since they were done by SGI and > SGI is now defunct. http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-mips@FreeBSD.ORG Thu Feb 19 01:24:41 2009 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65371065672; Thu, 19 Feb 2009 01:24:41 +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 5D3E28FC1A; Thu, 19 Feb 2009 01:24:41 +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 n1J1MqTx064206; Wed, 18 Feb 2009 18:22:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 18:23:01 -0700 (MST) Message-Id: <20090218.182301.112148095.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.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: kostikbel@gmail.com, mips@freebsd.org, tinderbox@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 01:24:42 -0000 In message: Marcel Moolenaar writes: : : On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: : > MIPS does define it as well. I have all the old o32 docs, but have : > had trouble locating the n32/n64 docs since they were done by SGI and : > SGI is now defunct. : : http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html Excellent! Thanks! It actually is still at techpubs.sgi.com too... I could have sworn I looked there a while ago only to find nothing running... Warner