From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30057 invoked by alias); 15 Jan 2015 22:42:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30041 invoked by uid 89); 15 Jan 2015 22:42:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.fgznet.ch Received: from mail.fgznet.ch (HELO smtp.fgznet.ch) (81.92.96.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 15 Jan 2015 22:42:16 +0000 Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id t0FMg6nG016827; Thu, 15 Jan 2015 23:42:09 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <54B8423E.2040405@fgznet.ch> Date: Thu, 15 Jan 2015 23:01:00 -0000 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Earnshaw , Ramana Radhakrishnan CC: GCC Patches Subject: Re: [PATCH][ARM] FreeBSD ARM support, EABI, v3 References: <54A1A0FB.60407@fgznet.ch> <54AEAFF5.6050008@arm.com> <54AEEDCE.8020302@fgznet.ch> <54B5894F.9020601@fgznet.ch> <54B63A3B.1090505@arm.com> In-Reply-To: <54B63A3B.1090505@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg01280.txt.bz2 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 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