MK_ARM_EABI to retire in current

[Warner Losh]

On May 22, 2014, at 9:52 AM, John Hay <jhay at meraka.org.za> wrote:

> On Thu, May 22, 2014 at 08:07:34AM -0600, Warner Losh wrote:
>> 
>> On May 22, 2014, at 3:05 AM, John Hay <jhay at meraka.org.za> wrote:
>> 
>>> On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote:
>>>> 
>>>> On May 21, 2014, at 1:28 PM, John Hay <jhay at meraka.org.za> wrote:
>>>> 
>>>>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote:
>>>>>> isn't eabi on the xscale still broken?
>>>>> 
>>>>> It might still be broken. But there are more brokenness than that. :-(
>>>>> By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel
>>>>> built that boots with src from head at around mid December. Latest 10
>>>>> and head just give no output, with or without WITHOUT_ARM_EABI defined.
>>>> 
>>>> Does the same thing happen with make.conf instead of src.conf?
>>> 
>>> Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no
>>> output after go in redboot. My compile lines look like this:
>>> 
>>> make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain
>>> make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA DESTDIR=/arm/
>>> 
>>> And then in redboot "load -b 0x200000 kernel" to load it with tftp. And
>>> then "go".
>>> 
>>> The "no output" happened somewhere between mid December and beginning
>>> of Feb. I determined that before getting side tracked. I'll see in the
>>> next day or two if I can narrow that down.
>>> 
>>> If someone have patches so that WITHOUT_ARM_EABI=yes is not needed
>>> anymore, I'll test that too.
>> 
>> This is with gcc, not clang, right?
> 
> The default that the tree will do for the above commands. I did not force
> it one way or the other. The kernels that did boot, reported gcc 4.2.1

OK. Just making sure.

Warner


>> Warner
>> 
>> 
>>> John
>>> 
>>>> 
>>>> Warner
>>>> 
>>>>> John
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -a
>>>>>> 
>>>>>> 
>>>>>> On 19 May 2014 08:40, Warner Losh <imp at bsdimp.com> wrote:
>>>>>>> Greetings,
>>>>>>> 
>>>>>>> MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI.
>>>>>>> 
>>>>>>> So, to that end, I see two options:
>>>>>>> 
>>>>>>> (1) Retire and remove oabi support.
>>>>>>> (2) Retain oabi support, but change its name to armo and armoeb.
>>>>>>> 
>>>>>>> The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody.
>>>>>>> 
>>>>>>> Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi.
>>>>>>> 
>>>>>>> Comments?
>>>>>>> 
>>>>>>> Warner
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> freebsd-arm at freebsd.org mailing list
>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>>>>> _______________________________________________
>>>>>> freebsd-arm at freebsd.org mailing list
>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

-------------- 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/freebsd-arm/attachments/20140522/06c980dd/attachment.sig>