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.

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

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 ;)

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

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

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

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

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

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.

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.

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.

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.

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.

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

> 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

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

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

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

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

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

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

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

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

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.

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 :-)

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

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!

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!

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

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

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

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!

> 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

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/th 
umb2\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!

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
separately like '__errno.o' above, using and modifying the make file
from the above
(http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html#stm32_blink)
mentioned example. Resulted in the same
> undefined reference to `__errno'
message.
And also the same problem, when using -march=armv7-m instead of the
-mcpu sitch.

So we can rule out the IDE stuff, I think.

Also, I tried it on two different pcs. Both running winxp pro version
2002 sp2, and reacted the same way every time.

gee there has to be something.

Anyway, thankx a lot!