Re: [avr-gcc-list] 'avr-size' strange thing...

[Ned Konz]

On Tuesday 16 March 2004 11:24 am, John Yannakopoulos wrote:

> At first, I' m doing a avr-size to the object files (.o) of my code to
> get the section information (text, data, bss) of each one. Secondly, after
> linking, doing a avr-size to the a.out executable, the .text segment size
> seems to be approx. twice the sum of the .text segment size of each of the
> object files. Is there any idea what's happening here? What extra
> information the linker adds to the executable file, double-sizing the total
> .text bytes? This weird thing has gotten me out of my mind and I cannot
> find relevant information anywhere. Please help...
>

Are you linking with the avr-libc libraries or startup code?

If so, are you including the size of the objects pulled from those other 
modules (including the startup code, any library routines, multiply and 
divide routines if needed, etc.)?

You can use avr-nm to see what you haven't defined in your routines:

$ avr-nm -gu timer_example.o
         U __divmodsi4
         U __mulsi3
         U __stack
         U __udivmodsi4

So these four undefined (-gu gives you Global Undefined symbols) symbols have 
to come from somewhere.

Let's look at it a bit differently (sorting by address):

$ avr-nm --numeric-sort -g timer_example.o
         U __divmodsi4
         U __mulsi3
         U __stack
         U __udivmodsi4
00000000 T _vector_6
00000002 C delay_done
0000003c T stop_timer0
00000048 T start_timer0
000000b6 T udelay
0000017e T msdelay
00000246 T main

And the same thing on the executable:

$ avr-nm --numeric-sort -g timer_example
         w __init_mcucr__
         w __init_wdtcr__
00000016 W _init_
00000016 T _real_init_
00000046 W _vector_1
00000046 W _vector_10
00000046 W _vector_2
00000046 W _vector_3
00000046 W _vector_4
00000046 W _vector_5
00000046 W _vector_7
00000046 W _vector_8
00000046 W _vector_9
00000048 W _unexpected_
0000004a T _vector_6
00000086 T stop_timer0
00000092 T start_timer0
000000df A __stack
00000100 T udelay
000001c8 T msdelay
00000290 T main
0000030c T __mulsi3
00000342 T __udivmodsi4
00000390 T __divmodsi4
000003c6 T _etext
00800060 B __bss_start
00800060 D __data_start
00800060 B delay_done
00800060 D _edata
00800062 B __bss_end
00800062 B _end
00810000 ? __eeprom_end


So you see that between main and _etext the three library routines got added. 
Their size would be 0x3c6-0x30c, or 186 (decimal) bytes. Plus the 0x4a or 74
(decimal) bytes for vectors, etc.

The difference is 260 bytes, which is really close to the 186+74 we just came 
up with.

$ size timer_example.o
   text    data     bss     dec     hex filename
    706       0       0     706     2c2 timer_example.o

$ size timer_example
   text    data     bss     dec     hex filename
    966       0       2     968     3c8 timer_example

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

_______________________________________________
avr-gcc-list mailing list
address@hidden
http://www.avr1.org/mailman/listinfo/avr-gcc-list