svn commit: r266553 - head/release/scripts

[Warner Losh]

On May 24, 2014, at 10:53 AM, Tijl Coosemans <tijl at FreeBSD.org> 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 at 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.

I think we’re talking past each other here. It absolutely would be MACHINE_ARCH == x32. That would be the name. And you could have an x32 kernel, if you wanted. When we’re building in the FreeBSD build system, we’d absolutely need a second MACHINE_ARCH.

What you are doing here is confuse MACHINE_ARCH with MACHINE_CPUARCH.

If you look at how we handle this for MIPS you’ll see we do exactly this for MIPS N32, which is exact likely x32. You don’t have to have a n32 kernel to run n32 binaries (but in MIPS’ case you can, if you want).

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140524/77598c94/attachment.sig>