Re: [PATCH][ARM] FreeBSD ARM support, EABI, v3

[Andreas Tobler <andreast-list@fgznet.ch>]

On 14.01.15 10:43, Richard Earnshaw wrote:
> On 13/01/15 21:08, Andreas Tobler wrote:
>> On 13.01.15 11:25, Ramana Radhakrishnan wrote:
>>> On Thu, Jan 8, 2015 at 8:51 PM, Andreas Tobler <andreast-list@fgznet.ch> wrote:
>>>> On 08.01.15 17:27, Richard Earnshaw wrote:
>>>>>
>>>>> On 29/12/14 18:44, Andreas Tobler wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> here is the third attempt to support ARM with FreeBSD.
>>>>>>
>>>>>> In the meantime we found another issue in the unwinder where I had to
>>>>>> adapt some stuff.
>>>>>>
>>>>>> The unwind_phase2_forced function in libgcc calls a stop_fn function.
>>>>>> This stop_fn is in FreeBSD's libthr implementation and is called
>>>>>> thread_unwind_stop. This thread_unwind_stop is a generic function used
>>>>>> on all FreeBSD archs.
>>>>>>
>>>>>> The issue is now that this thread_unwind_stop expects a double int for
>>>>>> the exception_class, like on every other arch. For ARM EABI this
>>>>>> exception_class is an array of char which is passed in one register as
>>>>>> pointer vs. two registers for a double int.
>>>>>>
>>>>>> To solve this issue we defined the exception_class as double integer for
>>>>>> FreeBSD.
>>>
>>> My apologies for the slow response, some other work and then holidays
>>> intervened.
>>
>> Np, the only issue which made me hurry was the stage 4 entering this week.
>>
>>> >From my understanding of the ABI document the implementation is
>>> currently as mandated by the ABI. Also this isn't a part of the ABI
>>> that's available for the platform (here FreeBSD to manipulate and
>>> change as per it's wishes). ARM EHABI is special for software, making
>>> FreeBSD more "special" for ARM appears to be counter intuitive from my
>>> point of view. A number of exception unwinding libraries. for e.g.
>>> libobjc , libstdc++ all use this implementation of exception_class.
>>> Therefore this creates a divergence for the FreeBSD port which is
>>> different from everything else. I expect that a number of language run
>>> time support libraries that supported the ARM EHABI would be using
>>> such an implementation, therefore you need to fix every single
>>> implementation of this in every unwinder that supports the ARM EHABI
>>> which I expect to have been ported to in a number of libraries
>>> already. (I already see this in libobjc and libstdc++ in the GCC tree)
>>
>> Grr ;) I didn't want to hear this answer, but I expected it somehow.
>> My proposal was the least effort for me.
>> The other way round is going to be very hard. Maybe impossible.
>>
>> It is not only FreeBSD which is affected but also llvm and friends. They
>> use for exception_class uint64_t.
>>
>> I have to take a picture how the effort is and if it would be possible
>> to do such a change in FreeBSD and more important in llvm etc.
>>
>>> I would rather fix the thread_unwind_stop implementation in libthr for
>>> ARM EHABI rather than make this change.
>>
>> It wouldn't be a 'fix' but more a wrapper I think.
>>
>>>>>> This adaptation reduced the failure count in libstdc++ by about 40 fails.
>>>>>>
>>>>>> I build and test this port on a regular basis and I post the results to
>>>>>> the usual place.
>>>
>>> Thanks for doing this. I'm really glad that FreeBSD is finally moving to EABI.
>>
>
> I agree with Ramana on this one, I feel that FreeBSD trying to plough a
> slightly different furrow is just going to cause major problems for
> everyone.
>
> I don't believe a claim that LLVM can't be made to work with the
> standard EHABI data structures.  It can do this on Linux, so I can't
> conceive of any reason why it cannot also do so on FreeBSD.

Thanks for the feedback, both! I'm busy to get a picture and I come back 
as soon I have a plan.

It is not a technical problem, it is, from my point of view, a 
distribution issue. Iow, we 'shipped' ABI/API X and we want/have to 
change to ABI/API Y.
So it takes a while till I get the plan :)

Andreas