This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM bug in newlib?


Adding libgcc.a did solve the problem. Instruction support is no doubt the reason why
I did not need to link in libgcc.a for my PowerPC applications. Thanks for your help
with this.

joe

Jeff Johnston wrote:

> Joe Pencak wrote:
>
> >I have built newlib-1.12.0 to work with a GCC ARM cross compiler. Newlib
> >was configured as follows on a Pentium II running
> >Windows:
> >
> >
> >
> >>../newlib-1.12.0/configure \
> >>  --enable-languages=c \
> >>  --target=arm-elf \
> >>  --program-prefix=arm- \
> >>  --prefix=/usr/local/arm
> >>
> >>
> >
> >When I use function atoi() in my code, I get the following linker
> >errors:
> >
> >
> >
> >>\usr\local\arm\arm-elf\lib/libc.a(strtol.o)(.text+0x90): In function
> >>
> >>
> >`_strtol_r'
> >
> >
> >>:
> >>../../../../../newlib-1.12.0/newlib/libc/stdlib/strtol.c:186: undefined
> >>
> >>
> >referenc
> >
> >
> >>e to `__umodsi3'
> >>\usr\local\arm\arm-elf\lib/libc.a(strtol.o)(.text+0xa0):../../../../../newlib-1.
> >>
> >>
> >
> >
> >
> >>12.0/newlib/libc/stdlib/strtol.c:187: undefined reference to
> >>
> >>
> >`__udivsi3'
> >
> >The code was linked as follows:
> >
> >
> >
> >>arm-ld -d -b elf32-littlearm -e __start -EL -static -nostdlib
> >>
> >>
> >-nostartfiles -L\u
> >
> >
> >>sr\local\arm\arm-elf\lib  -T linker-arm-gcc.lcf  _vectors.o
> >>
> >>
> >_startup.o  exceptions
> >
> >
> >>.o  main.o -lc -lm -Map a.map -o a.elf
> >>
> >>
> >
> >References to __umodsi3 and __udivsi3 appear in divsi3.c in
> >machine/h8500 and machine/w65, but not in machine/arm.
> >Apparently, when newlib is built for ARM, there is no divsi3.c with the
> >necessary references. A bug?
> >I've built newlib like this for the PowerPC and had no such problem.
> >
> >
> Joe,
>
>   The function __udivsi3 and __umodsi3 are in libgcc, not newlib.
> Standard operations like
> multiply, divide, mod, etc.. can require the compiler to issue function
> calls which are resolved in
> libgcc.  In your case, it is a divide and a mod operation.  On platforms
> where there
> are insns to support such operations, the compiler simply generates the
> appropriate code.  Thus, you
> may see differences from platform to platform.
>
>   Try adding -lgcc to your link and remember to add a -L reference to
> the proper location of the
> libgcc for your compiler options (libgcc gets multilib'ed like newlib does).
>
> -- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]