Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 May 2014 11:57:44 -0700
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Ian Lepore <ian@freebsd.org>, Tijl Coosemans <tijl@freebsd.org>
Cc:        Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, Glen Barber <gjb@freebsd.org>, svn-src-head@freebsd.org, Warner Losh <imp@bsdimp.com>
Subject:   Re: svn commit: r266553 - head/release/scripts
Message-ID:  <5380EBA8.1030200@freebsd.org>
In-Reply-To: <1400955835.1152.323.camel@revolution.hippie.lan>
References:  <201405221922.s4MJM4Y9025265@svn.freebsd.org>	 <537F6706.6070509@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>

next in thread | previous in thread | raw e-mail | index | archive | help
On 05/24/14 11:23, Ian Lepore wrote:
> On Sat, 2014-05-24 at 18:53 +0200, Tijl Coosemans wrote:
>> On Sat, 24 May 2014 09:04:33 -0700 Nathan Whitehorn wrote:
>>> On 05/24/14 07:59, Tijl Coosemans wrote:
>>>> On Fri, 23 May 2014 17:29:48 -0600 Warner Losh wrote:
>>>>> On May 23, 2014, at 10:20 AM, Baptiste Daroussin <bapt@FreeBSD.org> wrote:
>>>>>> On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
>>>>>>> On 05/23/14 08:36, Baptiste Daroussin wrote:
>>>>>>>> On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
>>>>>>>>> Is there any chance of finally switching the pkg abi identifiers to just
>>>>>>>>> be uname -p?
>>>>>>>>> -Nathan
>>>>>>>> Keeping asking won't make it happen, I have explained a large number of time why it
>>>>>>>> happened, why it is not easy for compatibility and why uname -p is still not
>>>>>>>> representing the ABI we do support, and what flexibility we need that the
>>>>>>>> current string offers to us.
>>>>>>>>
>>>>>>>> if one is willing to do the work, please be my guess, just dig into the archives
>>>>>>>> and join the pkg development otherwise: no it won't happen before a while
>>>>>>>> because we have way too much work on the todo and this item is stored at the
>>>>>>>> very end of this todo.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Bapt
>>>>>>> I'm happy to do the work, and have volunteered now many times. If uname
>>>>>>> -p does not describe the ABI fully, then uname -p needs changes on the
>>>>>>> relevant platforms. Which are they? What extra flexibility does the
>>>>>>> string give you if uname -p describes the ABI completely?
>>>>>>> -Nathan
>>>>>> just simple examples in armv6:
>>>>>> - eabi vs oabi
>>>>>> - The different float abi (even if only one is supported for now others are
>>>>>>    being worked on)
>>>>>> - little endian vs big endian
>>>>> All of those are encoded in the MACHINE_ARCH + freebsd version, no exceptions
>>>>> on supported architectures that are tier 2 or higher. This seems like a weak reason.
>>>>>
>>>>>> the extras flexibilit is being able to say this binary do support freebsd i386
>>>>>> and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*
>>>>> Will there be a program to convert this new, special invention to the standard
>>>>> that we˘ve used for the past 20 years? If you need the flexibility, which I˘m not
>>>>> entirely sure I˘ve seen a good use case for. When would you have a x86 binary
>>>>> package? Wouldn˘t it be either i386 or amd64?
>>>> ABI isn't just about the instruction set.  It's also about the sizes of C
>>>> types (like pointers).  If I remember correctly, the pkg scheme was chosen
>>>> to allow for ABIs like x32 which use the 64 bit instruction set with 32
>>>> bit pointers.  MACHINE_ARCH would also be amd64 in this case.
>>> No, it wouldn't. MACHINE_ARCH would be something else (x32, probably) in
>>> such cases. MACHINE_ARCH (and uname -p, which reports it) is the FreeBSD
>>> ABI identifier and encodes 100% of the ABI information. This would be
>>> true even if there is never an x32 kernel.
>> No, there's no such thing as an x32 kernel.  It's an amd64 kernel that
>> supports a second userland ABI.  In C preprocessor terms they are
>> distinguished by (__amd64__ && _LP64) and (__amd64__ && !_LP64).
>> uname -p gives you the processor architecture (the __amd64__ bit) but
>> then you can still choose the sizes of standard C types (the _LP64 bit).
>> So far we've always had one ABI per processor architecture but this
>> is not strictly necessary.
>>
> All you have to do is look at the plethora of ARM ABIs we support (and
> the corresponding separate kernel for each) to see the falseness of that
> last sentence.  ARM variations include v4 vs v6, OABI vs EABI (calling
> and register usage standards), hard vs soft float, little vs big endian.
> Virtually all combinations of those are possible (there are a few combos
> we don't support), and each one has its own MACHINE_ARCH.
>

Exactly. This doesn't rely on the kernel either. The hw.machine_arch 
sysctl (what uname -p returns) gives the ABI of the calling binary 
rather than the kernel. So if you use a 32-bit uname (e.g. in a chroot) 
on an amd64 host, you get i386. The same will be true if and when we 
support a 32-bit amd64 userland -- even if there is no x32 kernel, an 
x32 uname will return "x32" (or "amd32" or whatever it ends up being 
called). That string will also appear in kern.supported_archs.

MACHINE_ARCH completely defines the ABI, without exception, because, as 
a matter of policy, that's what we have defined it to mean. If there are 
any circumstances where it does not -- and none have been offered so far 
-- those are simply bugs that need fixing.
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5380EBA8.1030200>