From owner-svn-src-user@FreeBSD.ORG Wed Feb 3 23:06:26 2010 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E859106566B for ; Wed, 3 Feb 2010 23:06:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 613C58FC1A for ; Wed, 3 Feb 2010 23:06:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id A6981582BD; Wed, 3 Feb 2010 16:34:48 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id OZypvfokBk8B; Wed, 3 Feb 2010 16:34:48 -0600 (CST) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-55-200.icecube.wisc.edu [172.16.55.200]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 859B6582A5; Wed, 3 Feb 2010 16:34:48 -0600 (CST) Message-ID: <4B69FA08.2070308@freebsd.org> Date: Wed, 03 Feb 2010 16:34:48 -0600 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.23 (X11/20091207) MIME-Version: 1.0 To: Warner Losh References: <201002032129.o13LT7kZ013039@svn.freebsd.org> In-Reply-To: <201002032129.o13LT7kZ013039@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r203446 - in user/imp/tbemd: . bin/pax cddl/lib/libdtrace cddl/lib/libzpool contrib/smbfs etc games/morse gnu/lib/csu gnu/lib/libgcc gnu/lib/libgomp gnu/lib/libstdc++ gnu/usr.bin gnu/us... X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 23:06:26 -0000 Warner Losh wrote: > Author: imp > Date: Wed Feb 3 21:29:06 2010 > New Revision: 203446 > URL: http://svn.freebsd.org/changeset/base/203446 > > Log: > Introduce MACHINE_CPUARCH. > > MACHINE is the specific kernel architecture for this machine. > MACHINE_ARCH is the specific CPU type (abi, word size, etc). > MACHINE_CPUARCH is the family of CPUs that's supported. > > Most of the tree conflates MACHINE_ARCH and MACHINE_CPUARCH since > historically they have been identical. However, there's now a reason > to to split the two concepts. NetBSD calls this MACHINE_CPU, but > that's already used for something else in FreeBSD, so MACHINE_CPUARCH > was selected instead. > > However, the sources in the tree have had a KLUDGE in the tree called > TARGET_BIG_ENDIAN to select which endian to compile the code for. > However, this is a cumbersome and awkward solution. MACHINE_ARCH > really does need to be different for different endian because users > use it for things like their path. Yet, the source tree also used > MACHINE_ARCH to figure out the MD code to use. This source often > supports multiple MACHINE_ARCHs. 'mips' supports 32 (and soon 64) bit > word sizes as well as big and little endian. 'arm' support both > endians. powerpc will soon support both 32-bit and 64-bit. > > These patches start to unwind this confusion. It implements > MACHINE_ARCH of mipsel, mipseb for the two endians of MIPS, as well as > arm and armeb for ARM. The names for ARM are historical accidents > (ARM was primarily little endian until relatively recently). These > names follow the NetBSD convetions. > > With these changes, "make buildworld TARGET=mips TARGET_ARCH=mipsel" > finishes. armeb and mipseb should work, but haven't been tested yet. > > Committed as one big chunk so that people can comment on the patches > as a whole and suggest improvements. > > Thanks for this! How does this work for ABIs? For big vs. little endian, most if not all of the userland support code is invariant. But in the 64/32 bit case, 32 and 64-bit PowerPC have wildly differing ABIs, to the point that there is extremely little overlap in the support code for things like libc and RTLD, and it doesn't make much sense to point them at the same directories. Should MACHINE_CPUARCH be different here, or is it worth introducing something like MACHINE_ABI as well? I suppose there are also individual hacks in Makefiles... -Nathan