ARM EABI directions

[Tim Kientzle]

>> 
>>>> +.if ${TARGET_ARCH} != ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} == "clang"
>>>> +.if (${TARGET_ARCH} == "arm" || ${TARGET_ARCH} == "armv6") && \
>>>> +${MK_ARM_EABI} != "no"
>>>> +TARGET_ABI=	gnueabi
>>>> +.else
>>>> +TARGET_ABI=	unknown
>>>> +.endif
>>> 
>>> We need to fix the gnueabi issue with arm.  machine_arch should always be enough to be self-hosting, and while I fixed the armv6 issue, this has cropped up in its place :(.
>> 
>> Personally, I would like to see us switch to gnueabi
>> entirely and drop the configuration options.
> 
> Me too, but that would mean breaking 9.x binaries on 10.x systems, so some thought must be exercised here.

Why?  ARM was Tier 2 for FreeBSD 9.x, and the FreeBSD
package builds still don't support ARM packages, so I'm
not convinced that would be a problem.

OTOH, I'm hoping we can get ARM to Tier 1 for 10.x, so
this will be a concern after that point.

> My preference would be to support building eabi binaries only, but have a kernel option that would allow execution of oabi binaries.

That would make sense.  ISTR a thread discussing whether
it was possible to transparently support both eabi and oabi
syscalls.

> Then again, we are also heading to the soft fp vs vfp issue too…

<sigh>  Yeah.

Tim