avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Yannakopoulos
Subject: Re: [avr-gcc-list] 'avr-size' strange thing...
Date: Wed, 17 Mar 2004 15:42:10 +0200 (EET)

Hi Ned, thanks for your response.

I fixed the problem, but I still cannot have a confident explanation.

I was creating an archive (avr-ar, avr-ranlib) of a library and then I was
linking this archive against my main.c file. In that case I was having the
problem desribed in my previous e-mail.

E.g. I had:
1) avr-ar rcv libtrxdrv.a ADC_driver.o LCD_driver.o RF_driver.o
2) avr-ranlib libtrxdrv.a
3) avr-gcc $(FLAGS) main.c -L./ -ltrxdrv

This problem disappeared when I linked the object files together with the
object file of the main.c file (natively), e.g.:

avr-gcc $(FLAGS) ADC_driver.o LCD_driver.o RF_driver.o main.o


What's going on here? Is it likely that at the executable file the compiler
fills in the Undefined symbols denoted in your e-mail for each object
file, and thus the final image's size is almost twofold? Can you propose
an explanation for this?

Best regards,

--
John Yannakopoulos.


On Tue, 16 Mar 2004, Ned Konz wrote:

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]