avr-size: Wie groß ist das Programm denn nun wirklich?

[Malte _. (malte)]

Hallo,
ich erhalte verschiedene Größenangaben, je nach Methode wie ich zähle:
avr-size main.elf
   text    data     bss     dec     hex filename
   6786     126     196    7108    1bc4 main.elf

avr-size main.hex
   text    data     bss     dec     hex filename
      0    6870       0    6870    1ad6 main.hex

egal wie ich bei ersterem text, data und bss zusammenaddiere oder 
abziehe, komme ich nicht auf die 6870 Bytes bei der zweiten Methode. Ich 
war bisher immer von text + (bss -data) ausgegangen, aber das passt doch 
nicht ganz.

mit avr-size *.o
erhalte ich:
   text    data     bss     dec     hex filename
    384       0       0     384     180 ad_converter.o
     84      42       0     126      7e calibration_config.o
    386       0       0     386     182 clock.o
   3269      55      13    3337     d09 control.o
    210       0       0     210      d2 da_output.o
    458       0       6     464     1d0 lcd.o
    186       0       0     186      ba main.o
    388       0      20     408     198 rs232_io.o
    289       0       1     290     122 scheduler.o
    160       0       0     160      a0 tools.o
    352      20       0     372     174 user_in.o
    126       8       0     134      86 validator.o

Addiere ich hier alle Werte für text, so ist die Summe (6292) kleiner 
als der Wert text bei avr-size main.elf.

Und zuguter letzt direkt ins .hex file geschaut, finde ich 429 Zeilen 
mit je 16 bytes, eine Zeile mit zwei Bytes (warum auch immer) und als 
vorletzte Zeile eine mit vier Bytes, die letze besitzt nur die 
Checksumme.
Macht zusammen immerhin die oben genannten 6870 bytes.

Wie passen nun die drei Werte zusammen?

Übrigens sind die Werte bei avr-size *.o für den gcc 4.1.0 abhängig von 
der Optimierung, wobei manche Dateien bei -O1, manche bei -O2 und manche 
bei -Os die kleinsten Werte haben. Ich hätte gererell bei -Os die 
kleinsten Größen erwartet.

[kosmonaut pirx (Gast)]

hallo,
nur kurz zu deiner zusammenrechnung der .o -files. da fehlen dir einfach 
die instruktionen aus der gcrt aus der avrlibc. und dann nicht zu 
vergessen die instruktionen aus der libgcc.S, die vom gcc bereitgestellt 
und auch in finalen .elf gelinkt wird.
bye kosmo

[Jörg W. (dl8dtl) (Moderator)]

Malte __ wrote:

> ich erhalte verschiedene Größenangaben, je nach Methode wie ich zähle:
> avr-size main.elf
>    text    data     bss     dec     hex filename
>    6786     126     196    7108    1bc4 main.elf

Der ROM-Verbrauch ist text + data (letzteres, weil ja die initializer
der initialisierten Daten auch im ROM hinterlegt werden müssen).

Der statische RAM-Verbrauch ist data + bss.  Da kommt noch der
dynamische Verbrauch für den Stack hinzu.

> avr-size main.hex
>    text    data     bss     dec     hex filename
>       0    6870       0    6870    1ad6 main.hex

Da ein Hex-File selbst keine section-Information hat, schlagen es die
binutils erstmal pauschal auf "data" zu.  In Wirklichkeit enthält das
Hex-File natürlich das ROM-Abbild.  Warum das hier weniger als text +
data aus deinem ELF-File sind, erschließt sich mir allerdings nicht.

> mit avr-size *.o

... bekommst du insbesondere keine exakte Angabe über den
bss-Verbrauch, da dieser in den verschieblichen Objekten noch in Form
sogenannter common blocks definiert wird, die erst vom Linker
überlagert werden.  Damit kennt erst der Linker deren tatsächlichen
Speicherverbrauch.  Das Ganze stammt aus FORTRAN-Zeiten und wurde in
die Unix-C-Compiler übernommen, weil man damit so schön schlampig
einfach "int foo;" in eine Header-Datei schreiben kann, und die im
Prinzip daraus resultierenden Definitionen der Variablen foo in jedem
Objektmodul dann vom Linker doch noch in nur ein einziges foo
verwandelt werden.  (Ich vermute mal, dass das "Ur-C" einfach noch gar
kein "extern"-Schlüsselwort besass.)

Im GCC kannst du das mit -fno-common übrigens verhindern.

Außerdem fehlt dir bei deinen .o-Dateien natürlich alles aus der
Bibliothek, vom startup-Code angefangen.

[hackklotz (Gast)]

> Wie passen nun die drei Werte zusammen?

LOL ja das ist wirklich komplett seltsam gelöst, typisch open source und 
von Linux kommend.

FLASH=xxxxx als Beispiel wäre ja auch zu einfach gewesen.

[Jörg W. (dl8dtl) (Moderator)]

hackklotz wrote:

> LOL ja das ist wirklich komplett seltsam gelöst, typisch open source und
> von Linux kommend.

[ ] Du hast Ahnung.
[ ] Du hast je mit etwas anderem als Windows und Linux zu tun gehabt.

[yalu (Gast)]

Hab's gerade mal an ein paar Beispielen ausprobiert: In allen Fällen
ist text+data im ELF-File gleich data im Hex-File, so wie man das
erwarten würde. Ich benutze binutils 2.17.

Bist du sicher, dass dass das Hex- und das ELF-File wirklich
zueinander gehören? Möglicherweise hast du das Programm geändert,
kompiliert und gelinkt, aber das Hex-File noch nicht aktualisiert. Bei
meinem Makefile bspw. wird das Hex-File erst beim Flashen des
Controllers generiert, nicht schon beim Kompilieren. Es ist damit die
meiste Zeit nicht aktuell.

[Malte _. (malte)]

Danke, für die Erklärung.
Mein Makefile erzeugt jedoch nach dem compilieren stets die .hex Datei.
Ich denk, ich weiß jetzt aber wo die Differenz herkommt:

avr-size main.elf
   text    data     bss     dec     hex filename
   6882     126     200    7208    1c28 main.elf
avr-size main.hex
   text    data     bss     dec     hex filename
      0    6966       0    6966    1b36 main.hex

avr-size main.eep
   text    data     bss     dec     hex filename
      0      42       0      42      2a main.eep

Demnach enthält die main.elf auch noch die EEprom Daten, die .hex 
logischwerweise jedoch nicht.

[Jörg W. (dl8dtl) (Moderator)]

Ja, das ist wahr, die section .eeprom wird in der Standardausgabe mit
zu "data" gerechnet.

Wenn du avr-size -A benutzt, bekommst du die Informationen 
detaillierter.