Date: Tue, 27 May 2014 21:40:38 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, svn-src-all@freebsd.org, Glen Barber <gjb@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts Message-ID: <20140527214038.17d00369@kalimero.tijl.coosemans.org> In-Reply-To: <85FABD2B-81BB-4E1A-B61E-4216A144A9DB@bsdimp.com> References: <201405221922.s4MJM4Y9025265@svn.freebsd.org> <20140523153619.GF72340@ivaldir.etoilebsd.net> <537F6EBC.3080008@freebsd.org> <20140523162020.GG72340@ivaldir.etoilebsd.net> <C5A59513-AF58-4749-BCD7-F54BB6F56E90@gmail.com> <20140524165940.3c687553@kalimero.tijl.coosemans.org> <5380C311.60201@freebsd.org> <20140524185345.263f230d@kalimero.tijl.coosemans.org> <1400955835.1152.323.camel@revolution.hippie.lan> <5380EBA8.1030200@freebsd.org> <20140525011307.142b41ab@kalimero.tijl.coosemans.org> <3CCAFAD3-FABE-40EF-ABF9-815FE5826349@bsdimp.com> <9FE34CE4-C71F-4806-9EF6-30CB1051C62F@bsdimp.com> <20140526113502.239db74d@kalimero.tijl.coosemans.org> <5383522F.30108@freebsd.org> <DAD3E386-6555-4C43-9BBA-F3BFD28CC19B@bsdimp.com> <20140527001811.3e9d3e8d@kalimero.tijl.coosemans.org> <05D1A11D-5985-42EA-84AD-209A8B51D391@bsdimp.com> <20140527093633.0a922e13@kalimero.tijl.coosemans.org> <85FABD2B-81BB-4E1A-B61E-4216A144A9DB@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 2014 07:18:06 -0600 Warner Losh wrote: > On May 27, 2014, at 1:36 AM, Tijl Coosemans <tijl@FreeBSD.org> wrote: >> On Mon, 26 May 2014 16:31:21 -0600 Warner Losh wrote: >>> On May 26, 2014, at 4:18 PM, Tijl Coosemans <tijl@FreeBSD.org> wrote:=20 >>>> On Mon, 26 May 2014 09:53:57 -0600 Warner Losh wrote: >>>>> On May 26, 2014, at 8:39 AM, Nathan Whitehorn <nwhitehorn@freebsd.org= > wrote: >>>>>> On 05/26/14 02:35, Tijl Coosemans wrote: >>>>>>> I suppose you could replace the "x86" in the pkg scheme with i386/a= md64, >>>>>>> but then you'd still be talking about i386:32, amd64:32 and amd64:64 >>>>>>> instead of x86:32, x86:x32 and x86:64. =20 >>>>>=20 >>>>> I suppose you could replace these by ?i386?, ?x32? (or ?amd64x32?) and >>>>> ?amd64? respectively. >>>>=20 >>>> So you're on an amd64 or mips64 system (as indicated by uname) but you >>>> want to use the 32-bit package if possible. How does your script know >>>> about the magic "x32", "amd64x32" or "mipsn32" strings? Wouldn't it be >>>> easier if you could just use "`uname -p`:32?? >>>=20 >>> Oh give me a break. You know it because you know you are building for >>> mipsn32 because that?s what you?ve set MACHINE_ARCH or TARGET_ARCH to, >>=20 >> No, MACHINE_ARCH or TARGET_ARCH is "amd64" or "mips64". You are building >> the 64-bit OS and then decide separately per package whether you want the >> ILP32 one or the LP64 one. >=20 > I think I understand why we?re talking past each other. This bit is wrong. > The LP64 one has a MACHINE_ARCH of ?amd64? or ?mips64?. The ILP32 one wi= ll > have MACHINE_ARCH of ?i386? or ?mips?. The weird ones (ILP32 with 64-bit > registers) will have a different MACHINE_ARCH of ?x32? or ?mipsn32?. > Selection can be done on a case by case basis, but this will be validated > against the supported_abis sysctl. There?s no need to have different names > here, the current standard ones do just fine, are completely sufficient a= nd > all inclusive. This is rather by definition, and your understanding of the > definition sounds flawed. >=20 > While we have limited support for building 32-bit binaries, it is to build > 32-bit binaries for a different MACHINE_ARCH. -m32 on amd64 creates i386 > binaries, not amd64:32 binaries. -m32 on powerpc64 creates powerpc binari= es, > not powerpc64:32 binaries. On mips, -mabi-n32 (I think the option is) is > required to create the mipsn32 binaries. In every single one of these cas= es, > there exists a MACHINE_ARCH that completely describes the binary. amd64:32 is provided by the -mx32 compiler flag. > So I?m still waiting for a use case that requires the new names. One has > not been articulated, and I don?t think one actually exists. Imagine you've built a system with MACHINE_ARCH amd64 and one with MACHINE_ARCH mips64. Now you want to populate these systems with a list of packages for which you wrote a script. These systems each support 2 ABIs: a native 64-bit one (amd64 and mips64) and a native 32-bit one (x32 and mipsn32). Both are native in the sense that they make full use of the instruction set. This is not like i386 on amd64 or mips o32 on mips64 because those are more like compat shims that operate under special (crippled) cpu modes that nobody uses unless they're stuck with old code. Both our ABIs on the other hand are native and equally valid and which one to use for a particular package depends entirely on the use case. If your use case requires more than 4G of address space you'll have to use the 64-bit package, otherwise you can use the 32-bit package which, depending on how pointer heavy the code is, may give a performance benefit. You make this choice for each of the packages in your list and add that information to your script. Now let's work with Nathan's patch which uses the following string to identify the pkg repository to fetch packages from: `uname -s`:`uname -r | cut -f 1 -d .`:`uname -p` On our two systems that would be FreeBSD:11:amd64 and FreeBSD:11:mips64. Now if your script has to install the 32-bit version of a package how can it go from those two strings to FreeBSD:11:x32 or FreeBSD:11:mipsn32 without a lookup table? I say, you can more easily indicate whether you want the 32-bit or 64-bit package by appending :32 or :64 to the original strings, so FreeBSD:11:amd64:32 and FreeBSD:11:mips64:32. Like I said in a reply to Nathan's patch, pkg could default to :32 or :64 for every arch so it can be left out in many cases. FreeBSD:11:i386 would then be equivalent to FreeBSD:11:i386:32, FreeBSD:11:amd64 to FreeBSD:11:amd64:64, etc. This also does not preclude the existence of a mipsn32 MACHINE_ARCH in case you want to build a pure mipsn32 system (including the kernel), but I wonder how many people would use that if it is possible to have a mips64 system run n32 binaries. I don't think many people would run a pure x32 system (with x32 kernel) so I don't see the need to have an "x32" value for MACHINE_ARCH (or TARGET_ARCH).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140527214038.17d00369>