EmbDev.net

Forum: ARM programming with GCC/GNU tools arm-elf-g++ generates large hex file


von Stephen R. (stereo)


Rate this post
useful
not useful
Hi,

I'm new to developing with ARM uC and have recently started working with
an Analog Devices ADuC7020.  I first made a couple of simple test
programs with arm-elf-gcc to ensure that my build environment was
working correctly and had no problems.  I then did the same with
arm-elf-g++ only to find that the hex which was produced was much much
larger!

I then created the following file:

int main ()
{
  while (1)
  {}

  return 0;
}

When this is compiled with arm-elf-gcc its produces a hex of 72B but
when compiled with arm-elf-g++ it produces a hex of 132952B (133kB)!  I
thought that g++ would add some overhead but I was not expecting this
much.

I'm using version 4.1.1 of arm-elf-gcc and arm-elf-g++

Is this normal?

Many Thanks,

Stephen

von Clifford S. (clifford)


Rate this post
useful
not useful
It should not of itself add any significant overhead, but it may depend
on the options you have selected. Post your build log so we can see.

I just built your code for an LPC3180 (ARM9) device (because that is
what I had most immediately to hand), and ended up with 356 bytes as C
code, and 288 bytes as C++. Given that this was compiled with -O3, and
your code will likely optimise to an empty function, most of this code
size will be down to the crt0.s runtime start-up (which for an ARM9 is
generally larger than an ARM7, because of the MMU for example).

Note that the sizes I have quoited are for raw binary not hex. I have no
idea why C++ compilation made it smaller, but there is certainly no
reason for it to get larger.

If you use the C++ standard library, it is likely that your code will
get significantly larger, but for the code posted it should make little
or no difference.

Clifford

von Clifford S. (clifford)


Rate this post
useful
not useful
I used v4.0.2 for the record.

von Stephen R. (stereo)


Rate this post
useful
not useful
I've removed crt0.S from the build just to simplify my problem finding.
The Object files created by the C and C++ compilers are of comparable
sizes which leads me to think that I'm linking extra libraries.

I've been using the makefile which comes with WinARM and haven't changed
any of the flags that it defines.  Below is the build log:

Compiling C++: ../Source/main.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/main.lst
-Wcast-qual -MD -MP -MF .dep/main.o.d  ../Source/main.cpp -o main.o
Linking: Stage3.elf
arm-elf-g++  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=main.lst   -Wcast-qual -MD
-MP -MF .dep/Stage3.elf.d      main.o   --output Stage3.elf
-nostartfiles -Wl,-Map=Stage3.map,--cref -lc  -lm -lc -lgcc
-TADuC7020.ld
Creating load file for Flash: Stage3.hex
arm-elf-objcopy -O ihex Stage3.elf Stage3.hex
Creating Extended Listing: Stage3.lss
arm-elf-objdump -h -S -C Stage3.elf > Stage3.lss
Creating Symbol Table: Stage3.sym
arm-elf-nm -n Stage3.elf > Stage3.sym

--Stephen

von Stephen R. (stereo)


Rate this post
useful
not useful
Hi,

After lots of reading I came accross the "-nostdlib" option for linking.
After adding this the size of the reduced dramatically.

Thank you Clifford for your time and help.

--Stephen

von Stephen R. (stereo)


Rate this post
useful
not useful
I spoke to soon =O(  Although adding the "-nostdlib" option reduced the
size of the output significantly it also added a plethora of errors when
I link source which includes classes.  I'm guessing that some libraries
which were excluded when I add the "-nostdlib" option are actually
required.  Below is the build log:

Assembling (ARM-only): ../Source/startup.S
arm-elf-gcc -c -mcpu=arm7tdmi  -I. -x assembler-with-cpp -DDebug
-Wa,-adhlns=../Source/startup.lst,-gdwarf-2 ../Source/startup.S -o
startup.o
Compiling C (ARM-only): ../Source/irq.c
arm-elf-gcc -c -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/irq.lst
-Wcast-qual -MD -MP -MF .dep/irq.o.d -Wnested-externs  -std=gnu99
-Wmissing-prototypes  -Wstrict-prototypes -Wmissing-declarations
../Source/irq.c -o irq.o
Compiling C++: ../Source/main.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/main.lst
-Wcast-qual -MD -MP -MF .dep/main.o.d  ../Source/main.cpp -o main.o
Compiling C++: ../Source/uart.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/uart.lst
-Wcast-qual -MD -MP -MF .dep/uart.o.d  ../Source/uart.cpp -o uart.o
Compiling C++: ../Source/interrupts.cpp
arm-elf-g++ -c  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=../Source/interrupts.lst
-Wcast-qual -MD -MP -MF .dep/interrupts.o.d  ../Source/interrupts.cpp -o
interrupts.o
Linking: Stage3.elf
arm-elf-g++  -mcpu=arm7tdmi  -I. -gdwarf-2 -DDebug  -O0 -Wall
-Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wunused -Wa,-adhlns=startup.lst   -Wcast-qual
-MD -MP -MF .dep/Stage3.elf.d startup.o  irq.o   main.o uart.o
interrupts.o   --output Stage3.elf -nostartfiles
-Wl,-Map=Stage3.map,--cref -nostdlib -lc -lg  -lm -lgcc
-TADuC7020.ld
uart.o: In function `CUART::Instance()':
../Source/uart.cpp:8: undefined reference to `__cxa_guard_acquire'
../Source/uart.cpp:8: undefined reference to `operator new(unsigned
long)'
../Source/uart.cpp:8: undefined reference to `__cxa_guard_release'
../Source/uart.cpp:8: undefined reference to `__cxa_guard_abort'
../Source/uart.cpp:10: undefined reference to `__gxx_personality_sj0'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_RaiseException_Phase2':
rm -f ../Source/*.lst
../../gcc-4.1.1/gcc/unwind.inc:75: undefined reference to `abort'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_SjLj_Resume':
../../gcc-4.1.1/gcc/unwind.inc:238: undefined reference to `abort'
c:/program
files/amontec/sdk4arm/gat/garm/bin/../lib/gcc/arm-elf/4.1.1\libgcc.a(unw 
ind-sjlj.o):
In function `_Unwind_SjLj_Resume_or_Rethrow':
../../gcc-4.1.1/gcc/unwind.inc:263: undefined reference to `abort'
collect2: ld returned 1 exit status

Thanks,

--Stephen

von Clifford S. (clifford)


Rate this post
useful
not useful
Stephen Roe wrote:
> After lots of reading I came accross the "-nostdlib" option for linking.
> After adding this the size of the reduced dramatically.

Yes, I have always used -nostdlib, although probably not for any other
reason than I copied it from a VxWorks build that I was migrating. I
have however found that it often overcomes problems people have with the
'wrong' standard library being selected based on other target options.
On the target I tested your code on, I had to rebuild the library to
support VFP hardware, so it was essential.

All that said, I am not sure why it would have linked any code that was
not explicitly called. Perhaps if you are still interested in getting to
teh bottom of this you could generate a map file and see what actually
got linked?

Clifford

von Stephen R. (stereo)


Attached files:

Rate this post
useful
not useful
> All that said, I am not sure why it would have linked any code that was
> not explicitly called. Perhaps if you are still interested in getting to
> teh bottom of this you could generate a map file and see what actually
> got linked?

I've attached the map file for the original example.  I've had to
compress it as it was too large to be attached in its native form.  I
don't see why
code is getting linked which isn't called.

--Stephen

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.