Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Aug 2013 19:00:59 +0200
From:      Mattia Rossi <mattia.rossi.mate@gmail.com>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: Reminder: Removal of WITHOUT_ARM_EABI
Message-ID:  <521E2CCB.4070804@gmail.com>
In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan>
References:  <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521E2CCB.4070804>