Well GCC 4.3 has been released for over a month. I look forward to Cortex M3 support in most GNU ARM cross compilers soon. Has anybody noticed an ARM cross compilers built from GCC 4.3 yet ??? Cheers.
on 10.04.2008 13:49
on 10.04.2008 19:49
Simon Ellwood wrote: > Well GCC 4.3 has been released for over a month. > > I look forward to Cortex M3 support in most GNU ARM cross compilers > soon. > > Has anybody noticed an ARM cross compilers built from GCC 4.3 yet ??? > > Cheers. Code Sourcery and Code Red have Cortex support in pre 4.3 versions.
on 11.04.2008 02:15
Simon Ellwood wrote: > Well GCC 4.3 has been released for over a month. > > I look forward to Cortex M3 support in most GNU ARM cross compilers > soon. > > Has anybody noticed an ARM cross compilers built from GCC 4.3 yet ??? You may test "YaWinARMteprelpack 2008/03 - yet another WinARM test/preliminary-package" I made. I have used the GNU gcc 4.3.0 sources. It works for me so far in a few small tests with LMI Stellaris and ST STM32. http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#winarm
on 15.04.2008 09:51
Martin Thomas wrote: > You may test "YaWinARMteprelpack 2008/03 - yet another WinARM > test/preliminary-package" I made. I have used the GNU gcc 4.3.0 sources. > It works for me so far in a few small tests with LMI Stellaris and ST > STM32. > http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#winarm Great news. I will try and find time to try it in the next couple of months. Keep up the good work ;)
on 19.04.2008 11:03
Martin Thomas wrote: > You may test "YaWinARMteprelpack 2008/03 - yet another WinARM > test/preliminary-package" I made. I have used the GNU gcc 4.3.0 sources. > It works for me so far in a few small tests with LMI Stellaris and ST > STM32. > http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#winarm Hello, I tested the "YaWinARMteprelpack 2008/03" and it worked perfectly in my project. If somebody is interested a STM32F103 demo is included: http://sourceforge.net/projects/chibios/ It can be compiled with both the Codesourcery GCC 4.2.1 and WinARM GCC 4.3.0, it looks like the 4.3.0 is able to produce faster code in this application. regards, Giovanni
on 20.04.2008 10:53
Giovanni Di Sirio wrote: > It can be compiled with both the Codesourcery GCC 4.2.1 and WinARM GCC > 4.3.0, it looks like the 4.3.0 is able to produce faster code in this > application. I performed some more tests on the GCC 4.3.0, the result are quite interesting even if not good news... If looks like GCC 4.3.0 generates about 10% larger ARM/THUMB code compared to GCC 4.2.2. The code is also slower so there must be some serious regressions in this new release. Looking in the generated code, I found that the compiler no more optimizes the tail-calls like GCC 4.2.2 did, it also generates branches to a single exit point for every function instead of generating a LDM locally. The missing tail-calls optimization also means that the code uses more stack RAM, and this can be really bad in multi-threaded embedded applications. Interesting enough, those are the same problems present in CodeSourcery 4.2.1, it looks like that CodeSourcery's "improvements" made it into the GCC mainline code. I recommend to stay away from 4.3.0 for any production code. It kinda works but the performance is terrible. It is only useful because the Cortex-M3 support, but the generated code is terrible. Of course this is a GCC 4.3.0 issue, it is not specific to WinARM. regards, Giovanni
on 20.04.2008 16:08
Giovanni Di Sirio wrote: > I performed some more tests on the GCC 4.3.0, the result are quite > interesting even if not good news... > > If looks like GCC 4.3.0 generates about 10% larger ARM/THUMB code > compared to GCC 4.2.2. The code is also slower so there must be some > serious regressions in this new release. > > Looking in the generated code, I found that the compiler no more > optimizes the tail-calls like GCC 4.2.2 did, it also generates branches > to a single exit point for every function instead of generating a LDM > locally. > The missing tail-calls optimization also means that the code uses more > stack RAM, and this can be really bad in multi-threaded embedded > applications. > > Interesting enough, those are the same problems present in CodeSourcery > 4.2.1, it looks like that CodeSourcery's "improvements" made it into the > GCC mainline code. I have seen some increase of code-size too but did not investigate this so far. Thanks for your detailed and interesting information on this. It might be worth to write a bug-report in the gcc bugzilla. I think for the gcc-developers a "regression" is more important than a "missed optimization" so there are chances that these issues raise more interest and hopefully get fixed soon. Maybe you can write an e-mail to Codesourery too after testing with the latest "G++ (lite)" version which currently is based on gcc 4.2.3 IRC. You may also look at the several options available to "tweak" the optimizer (arm-eabi-gcc --help=optimizer). Maybe a solution is already there and just needs to be enabled to get rid of the regressions. > I recommend to stay away from 4.3.0 for any production code. It kinda > works but the performance is terrible. It is only useful because the > Cortex-M3 support, but the generated code is terrible. Please submit a report to the gcc bugzilla and write the bug-ID here so we can follow the developments. Martin Thomas
on 20.04.2008 16:30
Martin Thomas wrote: > I have seen some increase of code-size too but did not investigate this > so far. Thanks for your detailed and interesting information on this. > It might be worth to write a bug-report in the gcc bugzilla. I think for > the gcc-developers a "regression" is more important than a "missed > optimization" so there are chances that these issues raise more interest > and hopefully get fixed soon. > > Maybe you can write an e-mail to Codesourery too after testing with the > latest "G++ (lite)" version which currently is based on gcc 4.2.3 IRC. > > You may also look at the several options available to "tweak" the > optimizer (arm-eabi-gcc --help=optimizer). Maybe a solution is already > there and just needs to be enabled to get rid of the regressions. > >> I recommend to stay away from 4.3.0 for any production code. It kinda >> works but the performance is terrible. It is only useful because the >> Cortex-M3 support, but the generated code is terrible. > > Please submit a report to the gcc bugzilla and write the bug-ID here so > we can follow the developments. > > Martin Thomas GCC 4.3.0 enforces the 8 bytes stack alignment just like CS-GCC 4.2.1 does. Using the option -mabi=apcs-gnu the compiler returns to the 4 bytes alignment (like the previous mainline GCC versions) and this reduces the code size and improves speed a bit. However my previous post findings already included the improvements found using this option. As you suggested I will give another look at the optimization options and the new CS release before submitting a bug report. I also have to create a minimal example in order to explain the problem. Giovanni Di Sirio
on 21.04.2008 19:32
Ok, I made some more tests and created a minimal example. Do you think
this is enough for a bug report ?
The code is compiled with "-mcpu=arm7tdmi -O2 -fomit-frame-pointer
-mabi=apcs-gnu".
/*
* Test code.
*/
void testfunc(int a, int b) {
abc(0, 0);
if (a > b)
dostuff(a, b);
else
dostuff(b, a);
}
/*
* GCC 4.2.2 (YAGARTO, unmodified GCC).
* Note, it does tail calls optimization and functions can have multiple
* exit points.
*/
testfunc:
stmfd sp!, {r4, r5, lr}
mov r5, r0
mov r0, #0
mov r4, r1
mov r1, r0
bl abc
cmp r5, r4
ble .L20
mov r0, r5
mov r1, r4
ldmfd sp!, {r4, r5, lr}
b dostuff // Tail Call optimization.
.L20:
mov r0, r4
mov r1, r5
ldmfd sp!, {r4, r5, lr}
b dostuff // Tail Call optimization.
/*
* GCC 4.2.1 (CodeSourcery).
* No tail calls optimizations, single exit point, larger and slower
code.
*/
testfunc:
stmfd sp!, {r4, r5, lr}
mov r5, r0
mov r0, #0
mov r4, r1
mov r1, r0
bl abc
cmp r5, r4
ble .L20
mov r0, r5
mov r1, r4
bl dostuff // No Tail Call optimization.
.L23: // Single point exit code.
ldmfd sp!, {r4, r5, lr} // Why not just ", pc)" ?
bx lr // Extra return in the code path
and
// anyway wasted instruction
because
// no interworking is specified.
.L20:
mov r0, r4
mov r1, r5
bl dostuff // No Tail Call optimization.
b .L23 // Extra branch in the code path
and
// no space saved.
/*
* GCC 4.2.3 CodeSourcery.
* No changes since 4.2.1.
*/
testfunc:
stmfd sp!, {r4, r5, lr}
mov r5, r0
mov r0, #0
mov r4, r1
mov r1, r0
bl abc
cmp r5, r4
ble .L20
mov r0, r5
mov r1, r4
bl dostuff
.L23:
ldmfd sp!, {r4, r5, lr}
bx lr
.L20:
mov r0, r4
mov r1, r5
bl dostuff
b .L23
/*
* GCC 4.3.0.
* It is just like the CodeSourcery GCC now.
*/
testfunc:
stmfd sp!, {r4, r5, lr}
mov r5, r0
mov r0, #0
mov r4, r1
mov r1, r0
bl abc
cmp r5, r4
bgt .L19
mov r0, r4
mov r1, r5
bl dostuff
.L18:
ldmfd sp!, {r4, r5, lr}
bx lr
.L19:
mov r0, r5
mov r1, r4
bl dostuff
b .L18
Also note the wasted RAM space, dostuff() is invoked while the stack
holds 12
extra bytes compared to the mainline GCC 4.2.2.
I believe this is a problem in the ARM backend, unrelated to the other
changes in GCC 4.3.0. The overall effect in this example is:
- 4 bytes larger code.
- One or Two extra instructions in the code path.
- Faster growing stack because of no Tail Calls optimization, this is
really
bad in embedded multithreaded applications.
Giovanni
on 22.04.2008 17:13
Giovanni Di Sirio wrote: > Ok, I made some more tests and created a minimal example. Do you think > this is enough for a bug report ? >... I don't know what is "enough" since I do not know what a gcc developer needs but compared to some other reports in the bugzilla you provide a lot of information. Once there is an entry in the bugzilla there may be requests for additional information anyway. I suggest to add main() and dostuff() to the example so it's easy to reproduce the issue. You may also give the complete command line(s) to compiler and create the assembler-output.
on 22.04.2008 20:18
I found the root cause it seems. The generated code assumes -mthumb-interworking even if the option is not specified on the command line. By adding -mno-thumb-interworking the code will return to normal. The GCC 4.3.0 documentation states that the default is -mno-thumb-interworking because the slower and larger code generated by the interworking option. While this is still a bug it is a minor one. I will report it anyway but I need to know if this can be something specific to the WinARM build. I will run more tests in the meanwhile using more complex code, thank you.
on 22.04.2008 20:47
Giovanni Di Sirio wrote:
> I need to know if this can be something specific to the WinARM build.
Nevermind, it can't be, it also affects CodeSourcery compilers. I would
have edited the original post but it seems the forum does not allow
editing, sorry.
on 22.04.2008 21:15
Giovanni Di Sirio wrote: > Giovanni Di Sirio wrote: >> I need to know if this can be something specific to the WinARM build. > > Nevermind, it can't be, it also affects CodeSourcery compilers. I would > have edited the original post but it seems the forum does not allow > editing, sorry. Again thanks for the information. If they are not enabled by default somewhere inside the gcc sources the "thumb default" might be caused by the multlib-settings. I have used the settings from Codesourcery for gcc 4.2.x for the gcc 4.3.0 in WinARM 3/08 since there have been problems with the default settings that came with the official GNU 4.3.0 sources. Sorry, don't remember the exact error but will try do reproduce it with the next build. Attached is the file gcc/config/arm/t-arm-elf I have used for the gcc build in WinARM 3/08. The configuration is done like this: ../$GCC_SRC/configure \ --with-pkgversion="WinARM March 2008" --with-bugurl="http://en.mikrocontroller.net/forum/17" \ --target=$target --prefix=$prefix \ --disable-nls --disable-shared --disable-threads \ --with-gcc --with-gnu-ld --with-gnu-as \ --enable-languages=c,c++ --enable-interwork --enable-multilib \ --disable-libssp --disable-libstdcxx-pch --disable-libmudflap \ --disable-win32-registry --disable-libgomp --with-dwarf2 \ --program-prefix=$program_prefix \ --with-newlib \ --disable-newlib-supplied-syscalls --disable-libunwind-exceptions --disable-newlib-atexit-dynamic-alloc \ --with-gmp=$gmp_mpfr_root --with-mpfr=$gmp_mpfr_root \ -v || { echo "Error configuring gcc"; exit 1; } I currently to not see where "default for thumb" gets enabled. Suggestions are welcome. I will keep Michael Fischer informed so he may adapt the settings/configuration for his Yagarto precompiled toolchain too. I'm still not sure how to configure the multilib-settings of 4.3.0 so that they offer the best compatibility with all targets (big-endian. ARMv7 etc.). That's the main reason why WinARM 3/08 is just a "test-release". First of all I wanted to test support for Cortex-M3 devices from LMI and STmicro and the arm-eabi target. I had to modifiy the newlib-lpc a little bit too since the examples did not work with the previous arm-eabi WinARM and the 3/08 version (maybe cause by the "thumb default"). Porting has been done now and the newlib-lpc examples work and will be included in the next version's example collection again. Martin Thomas Edit: you may take a look on devkitarm r22. I have just noticed that the release 22 includes gcc 4.3.0 with a slightly different configuration, hopefully one day all this differences will be gone and there will be just one precompiled arm-cross toolchain for Win32 to avoid all this confusion. I have just downloaded dvekitarm r22 and will do some tests with it later this week.
on 23.04.2008 10:44
I ran some more detailed benchmarks: GCC 4.2.2: -O2 -mabi=apcs-gnu -mno-thumb-interworking -falign-functions=16 Total code size: 19348 *** Kernel Benchmark, context switch test #1 (optimal): Messages throughput = 141078 msgs/S, 282156 ctxswc/S *** Kernel Benchmark, context switch test #2 (no threads in ready list): Messages throughput = 111221 msgs/S, 222442 ctxswc/S *** Kernel Benchmark, context switch test #3 (04 threads in ready list): Messages throughput = 111223 msgs/S, 222446 ctxswc/S *** Kernel Benchmark, threads creation/termination: Threads throughput = 86642 threads/S *** Kernel Benchmark, I/O Queues throughput: Queues throughput = 343744 bytes/S GCC 4.3.0 -O2 -mabi=apcs-gnu -mno-thumb-interworking -falign-functions=16 Total code size: 19640 *** Kernel Benchmark, context switch test #1 (optimal): Messages throughput = 142316 msgs/S, 284632 ctxswc/S *** Kernel Benchmark, context switch test #2 (no threads in ready list): Messages throughput = 110945 msgs/S, 221890 ctxswc/S *** Kernel Benchmark, context switch test #3 (04 threads in ready list): Messages throughput = 110947 msgs/S, 221894 ctxswc/S *** Kernel Benchmark, threads creation/termination: Threads throughput = 93763 threads/S *** Kernel Benchmark, I/O Queues throughput: Queues throughput = 343736 bytes/S The results were obtained from a LPC2148 running at 48MHz. It seems GCC 4.3.0 still produces a bit larger code even if it seems to be a little faster on average. Note that the above code does not include any library so the code size is 100% an effect of the compiler. I will try devkitarm r22 too in the weekend, thank you.
on 03.07.2008 08:16
Martin Thomas wrote: > I'm still not sure how to configure the multilib-settings of 4.3.0 so > that they offer the best compatibility with all targets (big-endian. > ARMv7 etc.). That's the main reason why WinARM 3/08 is just a > "test-release". First of all I wanted to test support for Cortex-M3 > devices from LMI and STmicro and the arm-eabi target. I had to modifiy > the newlib-lpc a little bit too since the examples did not work with the > previous arm-eabi WinARM and the 3/08 version (maybe cause by the "thumb > default"). Porting has been done now and the newlib-lpc examples work > and will be included in the next version's example collection again. > Hi, Martin, I am working now on a project, where I need inline functions. As I know, GCC starts to support it only from the version 4.3.0, the one from your 3/08 WinARM package. But, unfortunately, linker does not recognize floating point functions. Please, can you upload to your WinARM site the new porting and examples, mentioned in your message, see above. Great thanks in advance, Varuzhan
on 03.07.2008 17:07
> But, unfortunately, linker does not recognize floating point > functions. output of the build process? at least the compiler-, linker-options and error-messages. > Please, can you upload to your WinARM site the new porting and examples, > mentioned in your message, see above. Maybe later next week, I currently do not have access to my archive. It may be a problem with my configuration so you may try DevkitARM r23 (comes with gcc 4.3) or Codesourcery's G++ lite (comes with gcc 4.2.x but extended for thumb2 support). If this still does not work double-check compiler/linker-options
on 03.07.2008 18:14
Martin Thomas wrote: >> But, unfortunately, linker does not recognize floating point >> functions. > > output of the build process? at least the compiler-, linker-options and > error-messages. > >> Please, can you upload to your WinARM site the new porting and examples, >> mentioned in your message, see above. > > Maybe later next week, I currently do not have access to my archive. > > It may be a problem with my configuration so you may try DevkitARM r23 > (comes with gcc 4.3) or Codesourcery's G++ lite (comes with gcc 4.2.x > but extended for thumb2 support). If this still does not work > double-check compiler/linker-options Hi, Martin, Thank you very much for response. I use you Makefile (adapted for my project), see below a fragment: # - 24. Aprl 2007 - added "both" option for format (.bin and .hex) # Toolchain prefix (i.e arm-elf -> arm-elf-gcc.exe) #TCHAIN = arm-elf #TCHAIN = arm-none-eabi TCHAIN = arm-eabi #FLASH_TOOL = UVISION #FLASH_TOOL = OPENOCD USE_THUMB_MODE = YES #USE_THUMB_MODE = NO # MCU name and submodel MCU = arm7tdmi-s SUBMDL = LPC2378 ## not supported in this example: ## Create ROM-Image (final) RUN_MODE=ROM_RUN ## Create RAM-Image (debugging) - not used in this example #RUN_MODE=RAM_RUN . . . MATH_LIB = -lm . . . With arm-elf and arm-none-eabi everything is Ok, but with arm-eabi I get a messages c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to `__aeabi_ddiv' c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to `__aeabi_dsub' c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to `__aeabi_dmul' for the line 433: BB = (Bulge - f)/4.0; where BB, Bulge and f are of double type. And similar messages for other floating point operations. Varuzhan
on 03.07.2008 21:39
> > With arm-elf and arm-none-eabi everything is Ok, but with arm-eabi I > get a messages > > c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to > `__aeabi_ddiv' > c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to > `__aeabi_dsub' > c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to > `__aeabi_dmul' > The missing symbols are either from libgcc or libc, probably libgcc. What linker commandline are you using? If you use gcc to link then it will resolve the symbols/paths for you. Regarding the other question above about interworking being enabled - this is defined in the arm-eabi spec as always being enabled by default. Cheers Spen
on 04.07.2008 08:20
Spencer Oliver wrote: >> >> With arm-elf and arm-none-eabi everything is Ok, but with arm-eabi I >> get a messages >> >> c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to >> `__aeabi_ddiv' >> c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to >> `__aeabi_dsub' >> c:\lates\lastsoft\md4a/Interpol.c:433: undefined reference to >> `__aeabi_dmul' >> > > The missing symbols are either from libgcc or libc, probably libgcc. > What linker commandline are you using? > > If you use gcc to link then it will resolve the symbols/paths for you. > > Regarding the other question above about interworking being enabled - > this is defined in the arm-eabi spec as always being enabled by default. > > Cheers > Spen Here are a linker part of Makefile #Additional libraries. # Extra libraries # Each library-name must be seperated by a space. # To add libxyz.a, libabc.a and libefsl.a: # EXTRA_LIBS = xyz abc efsl #EXTRA_LIBS = efsl EXTRA_LIBS = #Support for newlibc-lpc (file: libnewlibc-lpc.a) #NEWLIBLPC = -lnewlib-lpc MATH_LIB = -lm # CPLUSPLUS_LIB = -lstdc++ # Linker flags. # -Wl,...: tell GCC to pass this to linker. # -Map: create map file # --cref: add cross reference to map file LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref,--gc-sections LDFLAGS += -lc LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) LDFLAGS += -lc -lgcc LDFLAGS += $(CPLUSPLUS_LIB) LDFLAGS += $(patsubst %,-L%,$(EXTRA_LIBDIRS)) LDFLAGS += $(patsubst %,-l%,$(EXTRA_LIBS)) Varuzhan
on 04.07.2008 09:18
> > # Linker flags. > # -Wl,...: tell GCC to pass this to linker. > # -Map: create map file > # --cref: add cross reference to map file > LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref,--gc-sections > LDFLAGS += -lc > LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) > LDFLAGS += -lc -lgcc > LDFLAGS += $(CPLUSPLUS_LIB) > LDFLAGS += $(patsubst %,-L%,$(EXTRA_LIBDIRS)) > LDFLAGS += $(patsubst %,-l%,$(EXTRA_LIBS)) > I was more after the full command line rather than a makefile extract. Your makefile seems to be using gcc to perform the link. Try changing the flags as below: LDFLAGS += -lc -lgcc LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) LDFLAGS += -lc -lgcc if this still fails add the --verbose to the options, eg. LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref,--gc-sections,--verbose Cheers Spen
on 04.07.2008 09:54
Spencer Oliver wrote: >> >> # Linker flags. >> # -Wl,...: tell GCC to pass this to linker. >> # -Map: create map file >> # --cref: add cross reference to map file >> LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref,--gc-sections >> LDFLAGS += -lc >> LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) >> LDFLAGS += -lc -lgcc >> LDFLAGS += $(CPLUSPLUS_LIB) >> LDFLAGS += $(patsubst %,-L%,$(EXTRA_LIBDIRS)) >> LDFLAGS += $(patsubst %,-l%,$(EXTRA_LIBS)) >> > > I was more after the full command line rather than a makefile extract. > Your makefile seems to be using gcc to perform the link. Try changing > the flags as below: > > LDFLAGS += -lc -lgcc > LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) > LDFLAGS += -lc -lgcc > > if this still fails add the --verbose to the options, eg. > > LDFLAGS = -nostartfiles > -Wl,-Map=$(TARGET).map,--cref,--gc-sections,--verbose > > Cheers > Spen Thank you, --verbose helped to understand, that problem is not in linker flags, but in the library itself: attempt to open c:/winarm/bin/../lib/gcc/arm-eabi/4.3.0/../../../../arm-eabi/lib\libc.a succeededmain.o: In function `atof': f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_i2d' f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_dadd' f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_ddiv' f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_i2d' f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dmul' f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dadd' f:\lastsoft\md4a/main.c:231: undefined reference to `__aeabi_dmul' f:\lastsoft\md4a/main.c:253: undefined reference to `__aeabi_dmul' f:\lastsoft\md4a/main.c:255: undefined reference to `__aeabi_dmul' f:\lastsoft\md4a/main.c:259: undefined reference to `__aeabi_ddiv' f:\lastsoft\md4a/main.c:261: undefined reference to `__aeabi_dmul' Varuzhan
on 04.07.2008 10:50
> > attempt to open > c:/winarm/bin/../lib/gcc/arm-eabi/4.3.0/../../../../arm-eabi/lib\libc.a > succeededmain.o: In function `atof': > f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_i2d' > f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_dadd' > f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_ddiv' > f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_i2d' > f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dmul' > f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dadd' > f:\lastsoft\md4a/main.c:231: undefined reference to `__aeabi_dmul' > f:\lastsoft\md4a/main.c:253: undefined reference to `__aeabi_dmul' > f:\lastsoft\md4a/main.c:255: undefined reference to `__aeabi_dmul' > f:\lastsoft\md4a/main.c:259: undefined reference to `__aeabi_ddiv' > f:\lastsoft\md4a/main.c:261: undefined reference to `__aeabi_dmul' > > Varuzhan These functions are part of libgcc, just looked in the source. The problem is probably the order you are passing to the linker. You still haven't given me your full command-line + build log - this would really help. Cheers Spen
on 04.07.2008 11:02
Spencer Oliver wrote: >> >> attempt to open >> c:/winarm/bin/../lib/gcc/arm-eabi/4.3.0/../../../../arm-eabi/lib\libc.a >> succeededmain.o: In function `atof': >> f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_i2d' >> f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_dadd' >> f:\lastsoft\md4a/main.c:224: undefined reference to `__aeabi_ddiv' >> f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_i2d' >> f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dmul' >> f:\lastsoft\md4a/main.c:230: undefined reference to `__aeabi_dadd' >> f:\lastsoft\md4a/main.c:231: undefined reference to `__aeabi_dmul' >> f:\lastsoft\md4a/main.c:253: undefined reference to `__aeabi_dmul' >> f:\lastsoft\md4a/main.c:255: undefined reference to `__aeabi_dmul' >> f:\lastsoft\md4a/main.c:259: undefined reference to `__aeabi_ddiv' >> f:\lastsoft\md4a/main.c:261: undefined reference to `__aeabi_dmul' >> >> Varuzhan > > These functions are part of libgcc, just looked in the source. > The problem is probably the order you are passing to the linker. > > You still haven't given me your full command-line + build log - this > would really help. > > Cheers > Spen Ok, below is fill Makefile text # Hey Emacs, this is a -*- makefile -*- # # WinARM template makefile # by Martin Thomas, Kaiserslautern, Germany # <eversmith@heizung-thomas.de> # # based on the WinAVR makefile written by Eric B. Weddington, Jцrg Wunsch, et al. # Released to the Public Domain # Please read the make user manual! # # # On command line: # # make all = Make software. # # make clean = Clean out built project files. # # make program = Download the hex file to the device # # (TODO: make filename.s = Just compile filename.c into the assembler code only) # # To rebuild project do "make clean" then "make all". # # Changelog: # - 17. Feb. 2005 - added thumb-interwork support (mth) # - 28. Apr. 2005 - added C++ support (mth) # - 29. Arp. 2005 - changed handling for lst-Filename (mth) # - 1. Nov. 2005 - exception-vector placement options (mth) # - 15. Nov. 2005 - added library-search-path (EXTRA_LIB...) (mth) # - 2. Dec. 2005 - fixed ihex and binary file extensions (mth) # - 22. Feb. 2006 - added AT91LIBNOWARN setting (mth) # - 19. Apr. 2006 - option FLASH_TOOL (default lpc21isp); variable IMGEXT (mth) # - 23. Jun. 2006 - option USE_THUMB_MODE -> THUMB/THUMB_IW # - 3. Aug. 2006 - added -ffunction-sections -fdata-sections to CFLAGS # and --gc-sections to LDFLAGS. Only available for gcc 4 (mth) # - 4. Aug. 2006 - pass SUBMDL-define to frontend (mth) # - 11. Nov. 2006 - FLASH_TOOL-config, TCHAIN-config (mth) # - 28. Mar. 2007 - remove .dep-Directory with rm -r -f and force "no error" # - 24. Aprl 2007 - added "both" option for format (.bin and .hex) # Toolchain prefix (i.e arm-elf -> arm-elf-gcc.exe) #TCHAIN = arm-elf #TCHAIN = arm-none-eabi TCHAIN = arm-eabi #FLASH_TOOL = UVISION FLASH_TOOL = OPENOCD #USE_THUMB_MODE = YES USE_THUMB_MODE = NO # MCU name and submodel MCU = arm7tdmi-s SUBMDL = LPC2378 ## not supported in this example: ## Create ROM-Image (final) RUN_MODE=ROM_RUN ## Create RAM-Image (debugging) - not used in this example #RUN_MODE=RAM_RUN ## not supported in this example: ## Exception-Vector placement only supported for "ROM_RUN" ## (placement settings ignored when using "RAM_RUN") ## - Exception vectors in ROM: #VECTOR_LOCATION=VECTORS_IN_ROM ## - Exception vectors in RAM: #VECTOR_LOCATION=VECTORS_IN_RAM # Target file name (without extension). TARGET = main # List C source files here. (C dependencies are automatically generated.) # use file-extension c for "c-only"-files SRC = $(TARGET).c uart.c #SRC += Common/src/timer.c Common/src/target.c Common/src/irq.c SRC += Common/src/target.c Common/src/irq.c SRC += Init.c FRAM.c NVmirror.c Step.c Interface.c Interpol.c rprintf.c # List C source files here which must be compiled in ARM-Mode. # use file-extension c for "c-only"-files SRCARM = # List C++ source files here. # use file-extension cpp for C++-files (use extension .cpp) CPPSRC = # List C++ source files here which must be compiled in ARM-Mode. # use file-extension cpp for C++-files (use extension .cpp) #CPPSRCARM = $(TARGET).cpp CPPSRCARM = # List Assembler source files here. # Make them always end in a capital .S. Files ending in a lowercase .s # will not be considered source files but generated files (assembler # output from the compiler), and will be deleted upon "make clean"! # Even though the DOS/Win* filesystem matches both .s and .S the same, # it will preserve the spelling of the filenames, and gcc itself does # care about how the name is spelled on its command-line. ASRC = # List Assembler source files here which must be assembled in ARM-Mode.. ASRCARM = Common/src/Startup.S ASRCARM += Common/src/swi_handler.S # Path to Linker-Scripts LINKERSCRIPTPATH = Common/ ## Output format. (can be ihex or binary or both) ## (binary i.e. for openocd and SAM-BA, hex i.e. for lpc21isp and uVision) #FORMAT = ihex #FORMAT = binary FORMAT = both # Optimization level, can be [0, 1, 2, 3, s]. # 0 = turn off optimization. s = optimize for size. # (Note: 3 is not always the best optimization level. See avr-libc FAQ.) OPT = s #OPT = 0 ## Using the Atmel AT91_lib produces warning with ## the default warning-levels. ## yes - disable these warnings; no - keep default settings #AT91LIBNOWARN = yes AT91LIBNOWARN = no # Debugging format. # Native formats for AVR-GCC's -g are stabs [default], or dwarf-2. # AVR (extended) COFF requires stabs, plus an avr-objcopy run. #DEBUG = stabs DEBUG = dwarf-2 # List any extra directories to look for include files here. # Each directory must be seperated by a space. EXTRAINCDIRS = Common/inc # List any extra directories to look for library files here. # Each directory must be seperated by a space. #EXTRA_LIBDIRS = ../arm7_efsl_0_2_4 EXTRA_LIBDIRS = # Compiler flag to set the C Standard level. # c89 - "ANSI" C # gnu89 - c89 plus GCC extensions # c99 - ISO C99 standard (not yet fully implemented) # gnu99 - c99 plus GCC extensions CSTANDARD = -std=gnu99 # Place -D or -U options for C here CDEFS = -D$(RUN_MODE) # Place -I options here CINCS = # Place -D or -U options for ASM here ADEFS = -D$(RUN_MODE) ifdef VECTOR_LOCATION CDEFS += -D$(VECTOR_LOCATION) ADEFS += -D$(VECTOR_LOCATION) endif CDEFS += -D__WinARM__ -D__WINARMSUBMDL_$(SUBMDL)__ ADEFS += -D__WinARM__ -D__WINARMSUBMDL_$(SUBMDL)__ # Compiler flags. ifeq ($(USE_THUMB_MODE),YES) THUMB = -mthumb THUMB_IW = -mthumb-interwork else THUMB = THUMB_IW = endif # -g*: generate debugging information # -O*: optimization level # -f...: tuning, see GCC manual and avr-libc documentation # -Wall...: warning level # -Wa,...: tell GCC to pass this to the assembler. # -adhlns...: create assembler listing # # Flags for C and C++ (arm-elf-gcc/arm-elf-g++) CFLAGS = -g$(DEBUG) CFLAGS += $(CDEFS) $(CINCS) CFLAGS += -O$(OPT) CFLAGS += -Wall -Wcast-align -Wimplicit CFLAGS += -Wpointer-arith -Wswitch CFLAGS += -ffunction-sections -fdata-sections CFLAGS += -Wredundant-decls -Wreturn-type -Wshadow -Wunused CFLAGS += -Wa,-adhlns=$(subst $(suffix $<),.lst,$<) CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) # flags only for C CONLYFLAGS += -Wnested-externs CONLYFLAGS += $(CSTANDARD) ifneq ($(AT91LIBNOWARN),yes) #AT91-lib warnings with: CFLAGS += -Wcast-qual CONLYFLAGS += -Wmissing-prototypes CONLYFLAGS += -Wstrict-prototypes CONLYFLAGS += -Wmissing-declarations endif # flags only for C++ (arm-elf-g++) # CPPFLAGS = -fno-rtti -fno-exceptions CPPFLAGS = # Assembler flags. # -Wa,...: tell GCC to pass this to the assembler. # -ahlns: create listing # -g$(DEBUG): have the assembler create line number information ASFLAGS = $(ADEFS) -Wa,-adhlns=$(<:.S=.lst),-g$(DEBUG) #Additional libraries. # Extra libraries # Each library-name must be seperated by a space. # To add libxyz.a, libabc.a and libefsl.a: # EXTRA_LIBS = xyz abc efsl #EXTRA_LIBS = efsl EXTRA_LIBS = #Support for newlibc-lpc (file: libnewlibc-lpc.a) #NEWLIBLPC = -lnewlib-lpc MATH_LIB = -lm # CPLUSPLUS_LIB = -lstdc++ # Linker flags. # -Wl,...: tell GCC to pass this to linker. # -Map: create map file # --cref: add cross reference to map file LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref,--gc-sections,--verbose LDFLAGS += -lc LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) LDFLAGS += -lc -lgcc LDFLAGS += $(CPLUSPLUS_LIB) LDFLAGS += $(patsubst %,-L%,$(EXTRA_LIBDIRS)) LDFLAGS += $(patsubst %,-l%,$(EXTRA_LIBS)) # Set Linker-Script Depending On Selected Memory and Controller ifeq ($(RUN_MODE),RAM_RUN) LDFLAGS +=-T$(LINKERSCRIPTPATH)/$(SUBMDL)-RAM.ld else LDFLAGS +=-T$(LINKERSCRIPTPATH)/$(SUBMDL)-ROM.ld endif # --------------------------------------------------------------------------- # Flash-Programming support using lpc21isp by Martin Maurer # only for Philips LPC and Analog ADuC ARMs # # Settings and variables: #LPC21ISP = lpc21isp LPC21ISP = lpc21isp LPC21ISP_PORT = com5 LPC21ISP_BAUD = 9600 LPC21ISP_XTAL = 12000 # other options: # * verbose output: -debug # * enter bootloader via RS232 DTR/RTS (only if hardware supports this # feature - see Philips AppNote): -control LPC21ISP_OPTIONS = -control -wipe -verify #LPC21ISP_OPTIONS += -debug # --------------------------------------------------------------------------- # Define directories, if needed. ## DIRARM = c:/WinARM/ ## DIRARMBIN = $(DIRAVR)/bin/ ## DIRAVRUTILS = $(DIRAVR)/utils/bin/ # Define programs and commands. SHELL = sh CC = $(TCHAIN)-gcc CPP = $(TCHAIN)-g++ AR = $(TCHAIN)-ar OBJCOPY = $(TCHAIN)-objcopy OBJDUMP = $(TCHAIN)-objdump SIZE = $(TCHAIN)-size NM = $(TCHAIN)-nm REMOVE = rm -f REMOVEDIR = rm -f -r COPY = cp # Define Messages # English MSG_ERRORS_NONE = Errors: none MSG_BEGIN = "-------- begin (mode: $(RUN_MODE)) --------" MSG_END = -------- end -------- MSG_SIZE_BEFORE = Size before: MSG_SIZE_AFTER = Size after: MSG_FLASH = Creating load file for Flash: MSG_EXTENDED_LISTING = Creating Extended Listing: MSG_SYMBOL_TABLE = Creating Symbol Table: MSG_LINKING = Linking: MSG_COMPILING = Compiling C: MSG_COMPILING_ARM = "Compiling C (ARM-only):" MSG_COMPILINGCPP = Compiling C++: MSG_COMPILINGCPP_ARM = "Compiling C++ (ARM-only):" MSG_ASSEMBLING = Assembling: MSG_ASSEMBLING_ARM = "Assembling (ARM-only):" MSG_CLEANING = Cleaning project: MSG_FORMATERROR = Can not handle output-format MSG_LPC21_RESETREMINDER = You may have to bring the target in bootloader-mode now. # Define all object files. COBJ = $(SRC:.c=.o) AOBJ = $(ASRC:.S=.o) COBJARM = $(SRCARM:.c=.o) AOBJARM = $(ASRCARM:.S=.o) CPPOBJ = $(CPPSRC:.cpp=.o) CPPOBJARM = $(CPPSRCARM:.cpp=.o) # Define all listing files. LST = $(ASRC:.S=.lst) $(ASRCARM:.S=.lst) $(SRC:.c=.lst) $(SRCARM:.c=.lst) LST += $(CPPSRC:.cpp=.lst) $(CPPSRCARM:.cpp=.lst) # Compiler flags to generate dependency files. ### GENDEPFLAGS = -Wp,-M,-MP,-MT,$(*F).o,-MF,.dep/$(@F).d GENDEPFLAGS = -MD -MP -MF .dep/$(@F).d # Combine all necessary flags and optional flags. # Add target processor to flags. ALL_CFLAGS = -mcpu=$(MCU) $(THUMB_IW) -I. $(CFLAGS) $(GENDEPFLAGS) ALL_ASFLAGS = -mcpu=$(MCU) $(THUMB_IW) -I. -x assembler-with-cpp $(ASFLAGS) # Default target. all: begin gccversion sizebefore build sizeafter finished end ifeq ($(FORMAT),ihex) build: elf hex lss sym hex: $(TARGET).hex IMGEXT=hex else ifeq ($(FORMAT),binary) build: elf bin lss sym bin: $(TARGET).bin IMGEXT=bin else ifeq ($(FORMAT),both) build: elf hex bin lss sym hex: $(TARGET).hex bin: $(TARGET).bin else $(error "$(MSG_FORMATERROR) $(FORMAT)") endif endif endif elf: $(TARGET).elf lss: $(TARGET).lss sym: $(TARGET).sym # Eye candy. begin: @echo @echo $(MSG_BEGIN) finished: @echo $(MSG_ERRORS_NONE) end: @echo $(MSG_END) @echo # Display size of file. HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex ELFSIZE = $(SIZE) -A $(TARGET).elf sizebefore: @if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); echo; fi sizeafter: @if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); echo; fi # Display compiler version information. gccversion : @$(CC) --version # Program the device. ifeq ($(FLASH_TOOL),UVISION) # Program the device with Keil's uVision (needs configured uVision-Workspace). program: $(TARGET).hex @echo @echo "Programming with uVision" # C:\Keil\uv3\Uv3.exe -f uvisionflash.Uv2 -ouvisionflash.txt $(REMOVE) ../Common_WinARM/$(TARGET).hex $(COPY) $(TARGET).hex ../Common_WinARM/ C:\Keil\uv3\Uv3.exe -f ..\Common_WinARM\uvisionflash.Uv2 else ifeq ($(FLASH_TOOL),OPENOCD) # Program the device with Dominic Rath's OPENOCD in "batch-mode", needs cfg and "reset-script". program: $(TARGET).bin @echo @echo "Programming with OPENOCD" openocd_start_flash.cmd #OOCD_load_image=$(TARGET).bin #include oocd_flashing.mk #program : $(TARGET).bin oocd_programprepare oocd_programdoit #program : $(TARGET).bin oocd_programdoit else # Program the device. - lpc21isp will not work for SAM7 program: $(TARGET).hex @echo @echo $(MSG_LPC21_RESETREMINDER) $(LPC21ISP) $(LPC21ISP_OPTIONS) $(TARGET).hex $(LPC21ISP_PORT) $(LPC21ISP_BAUD) $(LPC21ISP_XTAL) endif endif # Create final output file (.hex) from ELF output file. %.hex: %.elf @echo @echo $(MSG_FLASH) $@ $(OBJCOPY) -O ihex $< $@ # Create final output file (.bin) from ELF output file. %.bin: %.elf @echo @echo $(MSG_FLASH) $@ $(OBJCOPY) -O binary $< $@ # Create extended listing file from ELF output file. # testing: option -C %.lss: %.elf @echo @echo $(MSG_EXTENDED_LISTING) $@ $(OBJDUMP) -h -S -C $< > $@ # Create a symbol table from ELF output file. %.sym: %.elf @echo @echo $(MSG_SYMBOL_TABLE) $@ $(NM) -n $< > $@ # Link: create ELF output file from object files. .SECONDARY : $(TARGET).elf .PRECIOUS : $(AOBJARM) $(AOBJ) $(COBJARM) $(COBJ) $(CPPOBJ) $(CPPOBJARM) %.elf: $(AOBJARM) $(AOBJ) $(COBJARM) $(COBJ) $(CPPOBJ) $(CPPOBJARM) @echo @echo $(MSG_LINKING) $@ $(CC) $(THUMB) $(ALL_CFLAGS) $(AOBJARM) $(AOBJ) $(COBJARM) $(COBJ) $(CPPOBJ) $(CPPOBJARM) --output $@ $(LDFLAGS) # $(CPP) $(THUMB) $(ALL_CFLAGS) $(AOBJARM) $(AOBJ) $(COBJARM) $(COBJ) $(CPPOBJ) $(CPPOBJARM) --output $@ $(LDFLAGS) # Compile: create object files from C source files. ARM/Thumb $(COBJ) : %.o : %.c @echo @echo $(MSG_COMPILING) $< $(CC) -c $(THUMB) $(ALL_CFLAGS) $(CONLYFLAGS) $< -o $@ # Compile: create object files from C source files. ARM-only $(COBJARM) : %.o : %.c @echo @echo $(MSG_COMPILING_ARM) $< $(CC) -c $(ALL_CFLAGS) $(CONLYFLAGS) $< -o $@ # Compile: create object files from C++ source files. ARM/Thumb $(CPPOBJ) : %.o : %.cpp @echo @echo $(MSG_COMPILINGCPP) $< $(CPP) -c $(THUMB) $(ALL_CFLAGS) $(CPPFLAGS) $< -o $@ # Compile: create object files from C++ source files. ARM-only $(CPPOBJARM) : %.o : %.cpp @echo @echo $(MSG_COMPILINGCPP_ARM) $< $(CPP) -c $(ALL_CFLAGS) $(CPPFLAGS) $< -o $@ # Compile: create assembler files from C source files. ARM/Thumb ## does not work - TODO - hints welcome ##$(COBJ) : %.s : %.c ## $(CC) $(THUMB) -S $(ALL_CFLAGS) $< -o $@ # Assemble: create object files from assembler source files. ARM/Thumb $(AOBJ) : %.o : %.S @echo @echo $(MSG_ASSEMBLING) $< $(CC) -c $(THUMB) $(ALL_ASFLAGS) $< -o $@ # Assemble: create object files from assembler source files. ARM-only $(AOBJARM) : %.o : %.S @echo @echo $(MSG_ASSEMBLING_ARM) $< $(CC) -c $(ALL_ASFLAGS) $< -o $@ # Target: clean project. clean: begin clean_list finished end clean_list : @echo @echo $(MSG_CLEANING) $(REMOVE) $(TARGET).hex $(REMOVE) $(TARGET).bin $(REMOVE) $(TARGET).obj $(REMOVE) $(TARGET).elf $(REMOVE) $(TARGET).map $(REMOVE) $(TARGET).obj $(REMOVE) $(TARGET).a90 $(REMOVE) $(TARGET).sym $(REMOVE) $(TARGET).lnk $(REMOVE) $(TARGET).lss $(REMOVE) $(COBJ) $(REMOVE) $(CPPOBJ) $(REMOVE) $(AOBJ) $(REMOVE) $(COBJARM) $(REMOVE) $(CPPOBJARM) $(REMOVE) $(AOBJARM) $(REMOVE) $(LST) $(REMOVE) $(SRC:.c=.s) $(REMOVE) $(SRC:.c=.d) $(REMOVE) $(SRCARM:.c=.s) $(REMOVE) $(SRCARM:.c=.d) $(REMOVE) $(CPPSRC:.cpp=.s) $(REMOVE) $(CPPSRC:.cpp=.d) $(REMOVE) $(CPPSRCARM:.cpp=.s) $(REMOVE) $(CPPSRCARM:.cpp=.d) $(REMOVEDIR) .dep | exit 0 # Include the dependency files. -include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*) # Listing of phony targets. .PHONY : all begin finish end sizebefore sizeafter gccversion \ build elf hex bin lss sym clean clean_list program Varuzhan
on 04.07.2008 11:35
I asked for the linker command-line not the makefile !! Sorry i do not have time to extract this from your makefile. did you try my first suggestion? LDFLAGS += -lc -lgcc LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) LDFLAGS += -lc -lgcc I do not use winarm, i build my own toolchain - so any help is generic. Cheers Spen
on 04.07.2008 11:40
Spencer Oliver wrote: > I asked for the linker command-line not the makefile !! > Sorry i do not have time to extract this from your makefile. > > did you try my first suggestion? > LDFLAGS += -lc -lgcc > LDFLAGS += $(NEWLIBLPC) $(MATH_LIB) > LDFLAGS += -lc -lgcc > > I do not use winarm, i build my own toolchain - so any help is generic. > > Cheers > Spen Yes, it does not helped.
on 17.07.2008 17:02
Hi,
I got pretty much the same problem:
my Compiler (gcc 4.3.0 testing) saying that he is missing some functions
here. The commands and output:
============================================================================
### Now biulding all the sources ##
arm-eabi-g++.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\cortexm3_macro.s -o
obj\Debug\lib\src\cortexm3_macro.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_adc.c -o
obj\Debug\lib\src\stm32f10x_adc.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_bkp.c -o
obj\Debug\lib\src\stm32f10x_bkp.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_can.c -o
obj\Debug\lib\src\stm32f10x_can.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_dma.c -o
obj\Debug\lib\src\stm32f10x_dma.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_exti.c -o
obj\Debug\lib\src\stm32f10x_exti.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_flash.c -o
obj\Debug\lib\src\stm32f10x_flash.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_gpio.c -o
obj\Debug\lib\src\stm32f10x_gpio.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_i2c.c -o
obj\Debug\lib\src\stm32f10x_i2c.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_iwdg.c -o
obj\Debug\lib\src\stm32f10x_iwdg.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_lib.c -o
obj\Debug\lib\src\stm32f10x_lib.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_nvic.c -o
obj\Debug\lib\src\stm32f10x_nvic.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_pwr.c -o
obj\Debug\lib\src\stm32f10x_pwr.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_rcc.c -o
obj\Debug\lib\src\stm32f10x_rcc.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_rtc.c -o
obj\Debug\lib\src\stm32f10x_rtc.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_spi.c -o
obj\Debug\lib\src\stm32f10x_spi.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_systick.c -o
obj\Debug\lib\src\stm32f10x_systick.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_tim.c -o
obj\Debug\lib\src\stm32f10x_tim.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_tim1.c -o
obj\Debug\lib\src\stm32f10x_tim1.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_usart.c -o
obj\Debug\lib\src\stm32f10x_usart.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_vector.c -o
obj\Debug\lib\src\stm32f10x_vector.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c lib\src\stm32f10x_wwdg.c -o
obj\Debug\lib\src\stm32f10x_wwdg.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c main.c -o obj\Debug\main.o
arm-eabi-gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3
-I. -Ilib -Ilib\inc -IC:\WinARM_4.3.0\arm-eabi\include
-IC:\WinARM_4.3.0\include -c stm32f10x_it.c -o obj\Debug\stm32f10x_it.o
## Now making an archive ##
arm-eabi-ar.exe -r -s libTEST_Soft.a obj\Debug\lib\src\cortexm3_macro.o
obj\Debug\lib\src\stm32f10x_adc.o obj\Debug\lib\src\stm32f10x_bkp.o
obj\Debug\lib\src\stm32f10x_can.o obj\Debug\lib\src\stm32f10x_dma.o
obj\Debug\lib\src\stm32f10x_exti.o obj\Debug\lib\src\stm32f10x_flash.o
obj\Debug\lib\src\stm32f10x_gpio.o obj\Debug\lib\src\stm32f10x_i2c.o
obj\Debug\lib\src\stm32f10x_iwdg.o obj\Debug\lib\src\stm32f10x_lib.o
obj\Debug\lib\src\stm32f10x_nvic.o obj\Debug\lib\src\stm32f10x_pwr.o
obj\Debug\lib\src\stm32f10x_rcc.o obj\Debug\lib\src\stm32f10x_rtc.o
obj\Debug\lib\src\stm32f10x_spi.o obj\Debug\lib\src\stm32f10x_systick.o
obj\Debug\lib\src\stm32f10x_tim.o obj\Debug\lib\src\stm32f10x_tim1.o
obj\Debug\lib\src\stm32f10x_usart.o obj\Debug\lib\src\stm32f10x_vector.o
obj\Debug\lib\src\stm32f10x_wwdg.o obj\Debug\main.o
obj\Debug\stm32f10x_it.o
arm-eabi-ar.exe: creating libTEST_Soft.a
Output size is 330.17 KB
## Now making elf ##
arm-eabi-gcc.exe
-Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -I. -Ilib/inc
-Llib -LC:/WinARM_4.3.0/arm-eabi/lib/thumb2
-LC:/WinARM_4.3.0/lib/gcc/arm-eabi/4.3.0/thumb2 -Tstm32.ld
libTEST_Soft.a --output main.elf
libTEST_Soft.a(main.o): In function `main':
C:\stm32_dev\project\TEST_soft_v1.0/main.c:49: undefined reference to
`__aeabi_dadd'
collect2: ld returned 1 exit status
============================================================================
here is the main (further functions don't really exist).
============================================================================
int main(void)
{
double a=0.0;
/* Infinite loop */
while (1){
a+=1.3;
}
return 0;
}
============================================================================
so I thought that I passed wrong or insufficient arguments to gcc. I
listed libgcc.a and libc.a looking for the absent function
"__aeabi_dadd", couldn't find it. May be I got this wrong? Are they
named differently and only renamed with one of the above build steps??
(Because one can choose the emulation by using -mfpu=XXX where XXX is
one of some implementations, ergo there being more than one
implementation of "_aeabi_dadd" they must have different names)
Thanks for your work on the WinARM!
Help :-)
on 17.07.2008 20:55
> > ## Now making elf ## > > arm-eabi-gcc.exe > -Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -I. -Ilib/inc > -Llib -LC:/WinARM_4.3.0/arm-eabi/lib/thumb2 > -LC:/WinARM_4.3.0/lib/gcc/arm-eabi/4.3.0/thumb2 -Tstm32.ld > libTEST_Soft.a --output main.elf > libTEST_Soft.a(main.o): In function `main': > C:\stm32_dev\project\TEST_soft_v1.0/main.c:49: undefined reference to > `__aeabi_dadd' > collect2: ld returned 1 exit status If you use gcc to link the you still need to tell it the target info. so when it passes the commands to ld all the correct directories etc will be set. try adding -mthumb -msoft-float -Wall -mcpu=cortex-m3 to the link stage arm-eabi-gcc.exe -mthumb -msoft-float -Wall -mcpu=cortex-m3 -Wl,--gc-sections,-Map=main.elf.map,-cref -I. -Ilib/inc -Llib -Tstm32.ld libTEST_Soft.a -o main.elf also the lib dirs do not need passing, as gcc will do this for you - if configured correctly. normally you would not add main to a lib, unsure why you are. why are you undefining Reset_Handler? make sure your entry point is defined otherwise you may have fun debugging with gdb. The following line in the linker script is very important for the cortex_m3 ENTRY(ResetISR) This needs to point to your reset vector, as remember on the cortex this is not 0x0 as other arm cores. Cheers Spen
on 21.07.2008 10:12
Hi, Thanks for your quick response! > try adding -mthumb -msoft-float -Wall -mcpu=cortex-m3 to the link stage Sounds logical to me. But gcc still tells me: arm-eabi-gcc -mthumb -msoft-float -Wall -mcpu=cortex-m3 -Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -I. -Ilib/inc -Llib -LC:/WinARM_4.3.0/arm-eabi/lib/thumb2 -LC:/WinARM_4.3.0/lib/gcc/arm-eabi/4.3.0/thumb2 -Tstm32.ld libSTM32-Template.a --output main.elf libSTM32-Template.a(main.o): In function `main': C:\stm32_dev\project\STM32-Template/main.c:50: undefined reference to `__aeabi_dadd' Just in general: has someone successfully build a project with floating point in it, for a thumb2 target with the above mentioned windows build of the gcc 4.3.0?? (http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/index.html ->'Another test-release: WinARM 20080331' -> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/winarmtests/WinARM_20080331_testing.zip) > normally you would not add main to a lib, unsure why you are. Right. But I shouldn't harm anyone, could it? Besides this was the most convenient way of setting up my IDE. > why are you undefining Reset_Handler? > make sure your entry point is defined otherwise you may have fun > debugging with gdb. > > The following line in the linker script is very important for the > cortex_m3 > ENTRY(ResetISR) > This needs to point to your reset vector, as remember on the cortex this > is not 0x0 as other arm cores. Well, I'm quite a noob at linker-scripts, and stuff. I adapted it from http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html#stm32_blink what was in the makefile. After you pointed out that the reset verctor is defined by 'ENTRY' I searched for it in the linker scrips, and for similar stuff in the *.c and *.h and *.s but couldn't find anything. Though it worked with the Codesourcery GNU-toolchain. And It works (including debug and stuff) with my present tool chain as well, as long as you don't use floating point in any form. I'm a bit confused right now. :-) If you want to, I could post parts of the main.elf.map. Thanx a lot!
on 28.07.2008 14:27
gOOOOOd mOOOrning! > After you pointed out that the reset verctor > is defined by 'ENTRY' I searched for it in the linker scrips, and for > similar stuff in the *.c and *.h and *.s but couldn't find anything. > Though it worked with the Codesourcery GNU-toolchain. I did some research (at last) and found the following in the ld manual (http://sourceware.org/binutils/docs-2.18/ld/Entry-Point.html#Entry-Point): >There are several ways to set the entry point. >The linker will set the entry point by trying each of the following methods >in order, and stopping when one of them succeeds: > > * the `-e' entry command-line option; > * the ENTRY(symbol) command in a linker script; > * the value of the symbol start, if defined; > * the address of the first byte of the `.text' section, if present; > * The address 0. Looking at the Linker-scrips, I think they define '.isr_vector' and point it to FLASH, thus being the first thing pointing to FLASH it shold be 0x08000000. After that they start writing their vector there, setting it up with ('stm32f10x_vector.c'): ========================================================================== __attribute__ ((section(".isr_vector"))) void (* const g_pfnVectors[])(void) = { &_estack, // The initial stack pointer Reset_Handler, // The reset handler NMIException, [...] }; ========================================================================== With 'Reset_Handler' being a c-fkt this will start executing it after a reset, effectively overriding the above mentioned procedure. But why there's an undefine for 'Reset_Handler' I don't know. So this more or less explains, why it runs :-) But I didn't get any further with floating point. You pointed out: >[...]also the lib dirs do not need passing, as gcc will do this for you - if >configured correctly. Maybe I did somthing wrong with the configuration, resulting in inproper library usage by the linker. Can you (or someone) tell what to configure, so I can check my config for errors? That would be nice :-) Another hint is the following thread: http://en.mikrocontroller.net/topic/160785 Martin Thomas states that there are libs compiled without floating point support, and that one could check on that, how do I do that. Listing the libgcc.a i found somthing with 'float' included in the name. grrr ??? cYa!
on 29.07.2008 12:48
Ahhh! Progress :-) So yesterday I tried some more stuff, that came to my mind: I took the libs from the Sourcery Gcc build (which is of course non-eabi) and put them where my winarm 4.3.0 libs were. Voila! It worked, I was able to compile my project with float / double in it (well it didn't work on the target because the winarm gcc is eabi and the sourcery libs are non-eabi but the linking worked), and debugging the target I was able to see that it did in fact work, besides the point that the mathematic operation just resulted in junk because of the different builds of the libs. So I guess that there is no float emulation build in the libs by Martin Thomas (may be he stated that somewhere and I just over read it :-). Now I will try to build the libs, by following the steps here: http://venus.billgatliff.com/node/18 I hope I succeed, by using cygwin... cYa
on 29.07.2008 18:24
> I took the libs from the Sourcery Gcc build (which is of course > non-eabi) and put them where my winarm 4.3.0 libs were. Very "hacky". > Voila! It > worked, I was able to compile my project with float / double in it (well > it didn't work on the target because the winarm gcc is eabi and the > sourcery libs are non-eabi but the linking worked), and debugging the > target I was able to see that it did in fact work, besides the point > that the mathematic operation just resulted in junk because of the > different builds of the libs. Everything in WinARM newer than 20060606 is "experimental" or "preliminery". I simply do not have the time to create a real new package where all examples have been somehow tested with an up-to-date toolchain. There are several "non-cygwin1.dll/reentrant-syscalls"-alternatives available now i.e.: DevkitARM, CS G++ (not sure about current newlib syscalls-config). So the Toolchain-part of WinArm is is at least parly obsolete. Anyway IRC I have created the binarys based on gcc 4.3.0 source as eabi-target (try arm-*-gcc --verbose which should show the config-paramters) > So I guess that there is no float emulation build in the libs by Martin > Thomas (may be he stated that somewhere and I just over read it :-). Maybe, but not by intention. > Now I will try to build the libs, by following the steps here: > http://venus.billgatliff.com/node/18 Try DevkitARM from DevkitPro first, it's a gcc 4.3.x arm-eabi-toolchain. Very similar to the WinARM configuration but hopefully different enough so FP will work as expected. > I hope I succeed, by using cygwin... First try DevkitARM. If it works it will save you a lot of time.
on 30.07.2008 13:38
Thanks for your response! >There are several >"non-cygwin1.dll/reentrant-syscalls"-alternatives available now i.e.: >DevkitARM, CS G++ (not sure about current newlib syscalls-config). So >the Toolchain-part of WinArm is is at least parly obsolete. CS G++ is semi proprietary therefor I would like to avoid it, but it works, I tried it before. Looking at DevkitARM R23b I can find no dir called 'thumb2', only 'thumb' in any of the lib sections. Though listing the target CPUs of the included gcc 'cortex-m3' is included. Is this toolchain able to create thumb2 instructions for the cortex-m3? I tried, and it only produced 'thumb' code resulting in inability to run on cortex-m3. Well, I could have configured it wrong, I passed -mthumb and -mcpu=cortex-m3 to every build step and didn't pass any lib-paths or so. It compiled without errors. But then producing expected errors on the target. btw: CS g++ got one arm-eabi version online, but this pages ultimately links to a arm-non-eabi version. Thanx again for your help :-) cYa
on 01.08.2008 13:19
Hi there! More 'great' news, I'm using the CG g++ now, because I'm desperate. Float and stuff is working BUT theres a problem with __errno. (I'm using 'sqrt' which calls '__errno') I'm sort of 'blown' by the fact, that there seam to be not ONE SINGLE gcc toolchain out there working for the cortex-m3. Man I got to do something wrong, this can't be! I (and probably everyone using the cortex-m3 :-) really need help, over here! Thank you!
on 01.08.2008 13:40
> More 'great' news, I'm using the CG g++ now, because I'm desperate. > Float and stuff is working BUT theres a problem with __errno. (I'm using > 'sqrt' which calls '__errno') > > I'm sort of 'blown' by the fact, that there seam to be not ONE SINGLE > gcc toolchain out there working for the cortex-m3. > > Man I got to do something wrong, this can't be! > > I (and probably everyone using the cortex-m3 :-) really need help, over > here! > > Thank you! I am unsure what you are doing wrong, but i can assure you gcc has been working fine for me and many others for over a year. I am using Anglia sarm toolchain but it is just a version of codesourcery. Also just tested using sqrt - ok here. Cheers Spen
on 01.08.2008 14:20
Hi, > I am unsure what you are doing wrong, but i can assure you gcc has been > working fine for me and many others for over a year. > > I am using Anglia sarm toolchain but it is just a version of > codesourcery. > Also just tested using sqrt - ok here. I just tested the Anglia sarm toolchain: Version: v1.62 not working: ============================================================================ #include "stm32f10x_lib.h" #include "math.h" int main(void) { double f=0.0, s=16.0; int i=0; s=sqrt(s); /* Infinite loop */ while (1){ /* insert CODE here */ i+=2; f+=2.0; /* insert CODE here */ } return 0; } ============================================================================ Compiling.... ============================================================================ g++.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3 -I. -Ilib -Ilib\inc -c lib\src\cortexm3_macro.s -o obj\Debug\lib\src\cortexm3_macro.o gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3 -I. -Ilib -Ilib\inc -c lib\src\stm32f10x_adc.c -o obj\Debug\lib\src\stm32f10x_adc.o gcc.exe .... ... (building the rest of the lib, without problems) gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3 -I. -Ilib -Ilib\inc -c main.c -o obj\Debug\main.o gcc.exe -g -DDEBUG -mthumb -msoft-float -Wall -mcpu=cortex-m3 -I. -Ilib -Ilib\inc -c stm32f10x_it.c -o obj\Debug\stm32f10x_it.o ar.exe -r -s libSTM32-Template.a obj\Debug\lib\src\cortexm3_macro.o obj\Debug\lib\src\stm32f10x_adc.o obj\Debug\lib\src\stm32f10x_bkp.o obj\Debug\lib\src\stm32f10x_can.o obj\Debug\lib\src\stm32f10x_dma.o obj\Debug\lib\src\stm32f10x_exti.o obj\Debug\lib\src\stm32f10x_flash.o obj\Debug\lib\src\stm32f10x_gpio.o obj\Debug\lib\src\stm32f10x_i2c.o obj\Debug\lib\src\stm32f10x_iwdg.o obj\Debug\lib\src\stm32f10x_lib.o obj\Debug\lib\src\stm32f10x_nvic.o obj\Debug\lib\src\stm32f10x_pwr.o obj\Debug\lib\src\stm32f10x_rcc.o obj\Debug\lib\src\stm32f10x_rtc.o obj\Debug\lib\src\stm32f10x_spi.o obj\Debug\lib\src\stm32f10x_systick.o obj\Debug\lib\src\stm32f10x_tim.o obj\Debug\lib\src\stm32f10x_tim1.o obj\Debug\lib\src\stm32f10x_usart.o obj\Debug\lib\src\stm32f10x_vector.o obj\Debug\lib\src\stm32f10x_wwdg.o obj\Debug\main.o obj\Debug\stm32f10x_it.o ar.exe: creating libSTM32-Template.a Output size is 317.24 KB ============================================================================ Linking... ============================================================================ Running project post-build steps cmd /C"gcc -Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -mthumb -mcpu=cortex-m3 -I. -Ilib/inc -Llib -Tstm32.ld libSTM32-Template.a --output main.elf" c:/anglia-sarm/bin/../lib/gcc/arm-eabi/4.2.3/../../../../arm-eabi/lib/thumb2\libm.a(lib_a-w_sqrt.o): In function `sqrt': C:\msys\1.0\home\soliver\sarm-build\newlib-stable-build\arm-eabi\thumb2\newlib\libm\math/../../../../../../newlib-stable/newlib/libm/math/w_sqrt.c:83: undefined reference to `__errno' C:\msys\1.0\home\soliver\sarm-build\newlib-stable-build\arm-eabi\thumb2\newlib\libm\math/../../../../../../newlib-stable/newlib/libm/math/w_sqrt.c:86: undefined reference to `__errno' Process terminated with status 1 (0 minutes, 8 seconds) 2 errors, 1 warnings ============================================================================ He is finding the lib, but not the errno. Maybe There's a problem with the build steps or something, but I can't really see where. (well I'm still making an *.a and then linking it to an *.elf, because of the IDE. Could this be the troublemaker) I really appreciate your quick response! Thank you!
on 01.08.2008 16:18
Hmmmm...
I just checked CS g++ again and looked for *errno*.o in libc.a, found
one: 'lib_a-errno.o'.
So it's there! I then extracted it from there with ar renamed it to
'__errno.o' and executed the following:
gcc -Wl,--gc-sections,-Map=main.elf.map,-cref,-u,Reset_Handler -mthumb
-mcpu=cortex-m3 -I. -Ilib/inc -Llib -Tstm32.ld libSTM32-Template.a
__errno.o --output main.elf
It linked!, and debugging on the target it worked too. So what is the
problem, why can't gcc/ld find it by its self?
To Spen:
When you say
> working fine for me and many others for over a year.
what commands are you using to compile and link the project. I just have
to do something wrong, because 'finding' stuff like floating point
emulation and so on works, why doesn't '__errno.o'???
btw. I also tried, not including the main.o in the *.a, and passed it
separatel