Reminder: Removal of WITHOUT_ARM_EABI

[Mattia Rossi]

Well, here's my input on this:

I've got around building a working kernel using CLANG (added option SCTP 
which fixed the alignment issue) and then got stuck at entropy 
harvesting. ^T doesn't do anything, nor does ^C.
So I rebuilt everything with -DWITHOUT_ARM_EABI. There I get:
Process (pid 1) got signal 11

Does a CLANG compiled world without EABI even work?

Cheers,

Mat

On 23/08/13 17:26, Ian Lepore wrote:
> On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote:
>> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As
>> this is planned on happening soon it this change is likely to happen
>> within the next two weeks, after a short heads up.
>>
>> This is a reminder for people who have not yet moved to the ARM EABI to
>> do so now as their build will break when this option is removed.
>>
> It turns out that on DreamPlug (armv5te) the unit won't boot all the way
> to multiuser mode with EABI, building with gcc or clang.  I first
> discovered this a few days ago when I realized I was still building with
> OABI on dreamplug and tried to switch.  I tried going back to a revision
> in late July but that didn't make any difference.  The before getting
> any further with bisecting I heard from Ilya Bakulin on irc that the
> problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to
> at least April.
>
> The rc.d/initrandom problem seems to be while running the 'df' command
> to "generate entropy."  In rc.d/var the problem is while running newfs
> on /dev/md0, and I can more readily confirm that -- if I use ^C to get
> past the hangs in rc.d processing it'll limp its way to multiuser mode,
> and if you manually try to "newfs /dev/md0" it definitely hangs the same
> way.  When it's hung in that state, a ^T gives no info, but a ^C does
> break out of the hang.  I've been unable to get any more info about
> how/why it's hung.
>
> I can understand a desire to not let any 10.0 release get into the wild
> with OABI support, but I'm not sure that removing the ability to even
> try OABI to see if it fixes a problem is a good idea.  EABI just doesn't
> have enough testing to declare that it's solid (because clearly it's not
> yet solid).  Can we declare that OABI isn't supported without removing
> the ability to fall back to it for testing purposes?  I wouldn't mind if
> enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_TESTING.
>
> -- Ian
>
>
> _______________________________________________
> 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"