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

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

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.


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
-------------- next part --------------
//===-- aeabi_idiv0.c - EABI idiv0 implementation -------------------------===//
//
//                     The LLVM Compiler Infrastructure
//
// This file is dual licensed under the MIT and the University of Illinois Open
// Source Licenses. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//


#ifdef __ARM_EABI__

extern void __aeabi_idiv0() __attribute__((weak));

void __aeabi_idiv0() {

}

#endif

-------------- next part --------------
//===-- aeabi_ldiv0.c - EABI ldiv0 implementation -------------------------===//
//
//                     The LLVM Compiler Infrastructure
//
// This file is dual licensed under the MIT and the University of Illinois Open
// Source Licenses. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//


#ifdef __ARM_EABI__

extern void __aeabi_ldiv0() __attribute__((weak));

void __aeabi_ldiv0() {

}

#endif

On 5 September 2014 19:10, Sergey Dmitrouk <sdmitrouk at accesssoftek.com>
wrote:
> #ifdef __ARM_EABI__
>     b __aeabi_idiv0
> #else
>     JMP(lr)
> #endif
Looks as though whomever implemented the call to __aeabi_idiv0 wanted
to be conservative for non EABI targets.

AFAIK, gnueabi targets recognize all EABI functions, so that should
work well. But I don't know about BSD, Darwin and other targets, how
they would behave if we assumed those functions were always there.

cheers,
--renato

Jon,

Thanks, I have similar stubs to be able to run programs.

Absence of these functions actually surprised me.  It's not very
friendly as dynamically linked applications just crash at startup (might
depend on dynamic linker though).

It'd be nice to have this documented somewhere, grepping current
compiler-rt repository gives me nothing except uses of idiv0.

Cheers,
Sergey

On Fri, Sep 05, 2014 at 11:32:30AM -0700, Jonathan Roelofs
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.
> 
> 
> 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

> Looks as though whomever implemented the call to __aeabi_idiv0 wanted
> to be conservative for non EABI targets.
How could it prevent him from providing default implementation of
__aeabi_idiv0() for EABI targets?
> AFAIK, gnueabi targets recognize all EABI functions, so that should
> work well.
Not sure I understand you, nothing in compiler-rt defines these
functions, they are left unresolved on gnueabit target for me.
> But I don't know about BSD, Darwin and other targets, how
> they would behave if we assumed those functions were always there.
We do assume they are always there for all EABI targets at the moment.
I'm wondering why it is so.  Is it left to be implemented in standard
library or something similar?

Thanks,
Sergey

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>