Hello,
I am trying to use long long division on ARM7 (LPC2103, LPC2129).
I wrote just a small program to test this something like:
int main(void)
{
volatile long long a,b,c;
a = b/c;
return 0;
}
If I try to compile this with the latest CodeSourcery tools 2007Q3,
the process failes with following output:
"-------- begin (mode: ROM_RUN) --------"
arm-none-eabi-gcc (CodeSourcery Sourcery G++ Lite 2007q3-53) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Compiling C: main.c
c:/tools/DEVEL/CodeSourcery\bin\arm-none-eabi-gcc -c -mcpu=arm7tdmi
-I. -gdwarf-2 -DROM_RUN -O1 -ffunction-sections -fdata-sections -Wall
-Wcast-align -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=main.lst -I./INC
-Wcast-qual -MD -MP -MF .dep/main.o.d -Wnested-externs -std=gnu99
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations main.c
-o main.o
ECHO is off.
Linking: main.elf
c:/tools/DEVEL/CodeSourcery\bin\arm-none-eabi-gcc -mcpu=arm7tdmi -I.
-gdwarf-2 -DROM_RUN -O1 -ffunction-sections -fdata-sections -Wall
-Wcast-align -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=startup.lst -I./INC
-Wcast-qual -MD -MP -MF .dep/main.elf.d startup.o arm_exc.o
low_level_init.o bsp.o isr.o SysTick.o rprintf.o uart.o cmd_parser.o
m_string.o PWM.o debug.o ADC.o MotorDrive.o backup.o iap.o chksum.o
main.o --output main.elf -nostartfiles
-Wl,-Map=main.map,--cref,--gc-sections -Tblinky.ld
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1\libgcc.a(
unwind-arm.o):
In function `get_eit_entry':
unwind-arm.c:(.text+0x7a0): undefined reference to `__exidx_start'
unwind-arm.c:(.text+0x7a4): undefined reference to `__exidx_end'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-abort.o):
In function `abort':
abort.c:(.text+0xc): undefined reference to `_exit'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-signalr.o):
In function `_getpid_r':
signalr.c:(.text+0x4): undefined reference to `_getpid'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-signalr.o):
In function `_kill_r':
signalr.c:(.text+0x2c): undefined reference to `_kill'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o):
In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
collect2: ld returned 1 exit status
cs-make[1]: *** [main.elf] Error 1
If I add to linker scripts following lines:
/* .ARM.exidx is sorted, so has to go in its own output section.
*/
.ARM.exidx : {
__exidx_start = .;
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
__exidx_end = .;
} >ROM
then the build failes with following output:
"-------- begin (mode: ROM_RUN) --------"
arm-none-eabi-gcc (CodeSourcery Sourcery G++ Lite 2007q3-53) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
ECHO is off.
Linking: main.elf
c:/tools/DEVEL/CodeSourcery\bin\arm-none-eabi-gcc -mcpu=arm7tdmi -I.
-gdwarf-2 -DROM_RUN -O1 -ffunction-sections -fdata-sections -Wall
-Wcast-align -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=startup.lst -I./INC
-Wcast-qual -MD -MP -MF .dep/main.elf.d startup.o arm_exc.o
low_level_init.o bsp.o isr.o SysTick.o rprintf.o uart.o cmd_parser.o
m_string.o PWM.o debug.o ADC.o MotorDrive.o backup.o iap.o chksum.o
main.o --output main.elf -nostartfiles
-Wl,-Map=main.map,--cref,--gc-sections -Tblinky.ld
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/bin/ld.exe:
main.elf: warning: sh_link not set for section `.ARM.exidx'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-abort.o):
In function `abort':
abort.c:(.text+0xc): undefined reference to `_exit'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-signalr.o):
In function `_getpid_r':
signalr.c:(.text+0x4): undefined reference to `_getpid'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-signalr.o):
In function `_kill_r':
signalr.c:(.text+0x2c): undefined reference to `_kill'
c:/tools/devel/codesourcery/bin/../lib/gcc/arm-none-eabi/4.2.1/../../../
../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o):
In function `_sbrk_r':
sbrkr.c:(.text+0x18): undefined reference to `_sbrk'
collect2: ld returned 1 exit status
cs-make[1]: *** [main.elf] Error 1
The same process with latest yagarto tools (arm-elf-gcc version 4.2.2),
and no modifications in linker script, compiles without errors.
I need to use CodeSourcery tools. Does anybody have a clue what am I
missing?
Thank you in advance,
alessio
It looks like you have not implemented the necessary syscalls. Since the code makes no library calls you might think that you need not do that, but long long is not a fundamental machine type on ARM, so the compiler may insert calls to functions for even basic operations on such a type. That's my guess in any case; the use of long long and caused 64bit support code to get linked, and that code includes the calls the linker says are missing. The syscall stubs are target specific and need to be implemented by you (or use/adapt one of the existing examples). Clifford
Clifford, thank you for your reply. I read about necessary syscall stubs in libm manual, but didn't need them up until now. Can anybody please give me some link where to start digging about those syscalls? I am still curious why does the same program compile without errors with yagarto arm-elf-gcc, but fails with CodeSourcery arm-none-eabi-gcc. Built program with yagarto needs additional 1kB of space for long long division and works OK. The only difference between successful and unsuccessful compilation is in makefile's COMPILER variable: COMPILER = elf ifeq ($(COMPILER),elf) # GNU-ARM tools directory GNU_ARM = c:/tools/DEVEL/yagarto # The gcc compiler and linker CC = $(GNU_ARM)\bin\arm-elf-gcc ASM = $(GNU_ARM)\bin\arm-elf-as LINK = $(GNU_ARM)\bin\arm-elf-gcc OBJCOPY = $(GNU_ARM)\bin\arm-elf-objcopy SIZE = $(GNU_ARM)\bin\arm-elf-size NM = $(GNU_ARM)/bin/arm-elf-nm OBJDUMP =$(GNU_ARM)/bin/arm-elf-objdump else # GNU-ARM tools directory GNU_ARM = c:/tools/DEVEL/CodeSourcery # The gcc compiler and linker CC = $(GNU_ARM)\bin\arm-none-eabi-gcc ASM = $(GNU_ARM)\bin\arm-none-eabi-as LINK = $(GNU_ARM)\bin\arm-none-eabi-gcc OBJCOPY = $(GNU_ARM)\bin\arm-none-eabi-objcopy SIZE = $(GNU_ARM)\bin\arm-none-eabi-size NM = $(GNU_ARM)/bin/arm-none-eabi-nm OBJDUMP =$(GNU_ARM)/bin/arm-none-eabi-objdump endif Regards, alessio
> I am still curious why does the same program compile without errors > with yagarto arm-elf-gcc, but fails with CodeSourcery arm-none-eabi-gcc. > Built program with yagarto needs additional 1kB of space for long long > division and works OK. > This is because codesourcery build newlib (c library) with --disable-newlib-supplied-syscalls whereas yagarto builds the default system calls. Also yagarto is a arm-elf toolchain, and the codesourcery is a arm-eabi toolchain. This syscalls interface did change slightly between the two aswell. Cheers Spen
Spencer Oliver wrote: > This is because codesourcery build newlib (c library) with > --disable-newlib-supplied-syscalls whereas yagarto builds the default > system calls. > > Also yagarto is a arm-elf toolchain, and the codesourcery is a arm-eabi > toolchain. > This syscalls interface did change slightly between the two aswell. Spen, I greatly appreciate your helpful reply. Can you say few words about what is the difference between arm-elf and arm-eabi toolchain? Do you have a link describing this, I have a lot more to learn. Cheers
> > Spen, I greatly appreciate your helpful reply. > > Can you say few words about what is the difference between arm-elf and > arm-eabi > toolchain? Do you have a link describing this, I have a lot more to > learn. > > Cheers for standalone apps you may notice no difference. It is really todo with a generic standard among targets/tools. For example, if you built a library using Realview you should be able to link it in with gcc source. Have a look on arm website for lots of other info. Cheers Spen
Spencer Oliver wrote: >[...] > > This is because codesourcery build newlib (c library) with > --disable-newlib-supplied-syscalls whereas yagarto builds the default > system calls. >[...] Sorry for repling on this old post, but i want to say 'Thanks alot!' for this clue. Im on this issue for the whole morning. So as far as i know by now i need to implement the missing marks _sbrk, _exit, _getpid and _kill bymyself. I'm pretty sure im not the only one with this issue. Is there a implementation i can use for this? google dont gives matches about. And i wonder if there is no way to just use a newlib with enabled syscalls. I could just re-compile (not using installer) the codesourcery w/o the disable option and use the built libc.a instead of my current. I'm thankfull for any clue bout this. Oh and bytheway im working on a cortex-m1
Qduda 12345 wrote: > Spencer Oliver wrote: > So as far as i know by now i need to implement the missing marks _sbrk, > _exit, _getpid and _kill bymyself. I'm pretty sure im not the only one > with this issue. Is there a implementation i can use for this? google > dont gives matches about. Read the "Building Bare-metal ARM with GNU" document in the ARM-GCC development resources sticky thread (http://embdev.net/topic/129986) > And i wonder if there is no way to just use a newlib with enabled > syscalls. I could just re-compile (not using installer) the codesourcery > w/o the disable option and use the built libc.a instead of my current. Many of the syscalls are target/platform specific, which is why they are not provided, they are what glue teh library you your specific hardware. In most cases you do not need to implement more than an empty stub, byt _sbrk is critical since it enables dynamic memory allocation and heap management.
I just implemented all of the missing references as stub function. Its working. All i wonder is why my linker wants a reference to _sbrk. I dont use functions useing memory allocation. The only "none-basic" function is "memcpy" which is part of string.h, and from what i know it dont use dynamic memory allocation. Another thing is this _getpid mark... no idea why the linker needs it... whatever i implemented stubs and its working. If anyone got the same issue, just try out if simple stub functions are working, it won't hurt. Thanks for advice!
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.