[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?

Saleem Abdulrasool compnerd at compnerd.org
Sat Sep 6 14:46:56 PDT 2014


On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

> Sergey,
>
> Not that it'll save you much hassle, but here's an implementation of
> __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while.
>
> I vaguely remember compnerd suggesting that I don't commit them to
> compiler_rt, but I don't remember why.
>

I did dig into this further and it seems that they are, in fact, considered
part of the RT-ABI :-(.  Ive committed a simple conforming implementation
in SVN r217322.


>
> Cheers,
>
> Jon
>
>
> On 9/5/14, 12:10 PM, Sergey Dmitrouk wrote:
>
>> Hi,
>>
>> There are several places in compiler-rt which refer to __aeabi_idiv0.
>> For example, in lib/builtins/arm/udivsi3.S:
>>
>> #ifdef __ARM_EABI__
>>      b __aeabi_idiv0
>> #else
>>      JMP(lr)
>> #endif
>>
>> At the same time there is no definition of it.  It looks as if it was
>> done intentionally so that third-party could provide custom handler for
>> division by zero.
>>
>> IMHO It's not very consistent and looks odd as all other __aebi_*
>> functions are provided by compiler-rt.
>>
>> Did I get it all right or maybe I'm missing something?
>>
>> libgcc provides both __aeabi_idiv0 and __aeabi_ldiv0 as weak symbols,
>> any reasons not to do the same in compiler-rt?  Or, to put it
>> differently, why force external implementation of these functions?
>>
>> Thanks,
>> Sergey
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140906/314dc41d/attachment.html>


More information about the llvm-dev mailing list