search for: __aeabi_ldiv0

...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

...that emulating GCC's behavior of the exception is what I was referring to. > Today we return either zero (in divmod/div/mod) or the argument (when > calling div0 directly), and that's just wrong. Quoting the RTABI: 1. int __aeabi_idiv0(int return_value); long long __aeabi_ldiv0(long long return_value); The *div0 functions: 􏰁 Return the value passed to them as a parameter. Is my copy out of date? > > Why 0 and not infinity? Or some other value? > > Because 0 is what it was before. > > cheers, > --renato > -- Saleem Abdulrasool compn...

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 simp...

...ned reference to `__aeabi_memset' /home/yanchao/research/musl-1.1.6/lib//libc.a(vfprintf.o): In function `vfprintf': src/stdio/vfprintf.c:(.text+0x28): undefined reference to `__aeabi_memset' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc.a(_dvmd_lnx.o): In function `__aeabi_ldiv0': (.text+0x8): undefined reference to `raise' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(unwind-arm.o): In function `unwind_phase2': unwind-arm.c:(.text+0xae4): undefined reference to `abort' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//li...

...int a) { > return __aeabi_idiv0(a); > } > > returns 'a', while: > > int bar(int a) { > return __aeabi_idiv(a, 0); > } > > returns zero. > > > > Quoting the RTABI: > > > > int __aeabi_idiv0(int return_value); > > long long __aeabi_ldiv0(long long return_value); > > > > The *div0 functions: > > > > 􏰁 Return the value passed to them as a parameter. > > > > Is my copy out of date? > > As I said before, all three behaviours are allowed by the RTABI > (exception, constant, parameter), but w...

On Sat, Sep 6, 2014 at 3:40 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 6 September 2014 22:46, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > 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. > >

> > FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I >> had to patch a few of the __attribute__((naked)) functions because they >> were using pre-UAL asm syntax, but for the most part it "just works". >> > I build the baremetal newlib using arm-none-eabi-gcc as well, but after linking with the hello world program, it failed to run on