Forum: Compiler & IDEs Wieviel Platz braucht mein Code wirklich.bin, .hex, .elf :?


von Rainer K. (Gast)


Lesenswert?

Hallo Zusammen,

ich habe hier auf dem Board in älteren Beiträgen gelesen, dass ich mit 
den binutils mir die Größe der Sections meines .elf files ausgeben kann. 
Weiter wurde beschrieben das sich der ROM Speicherverbrauch aus 
DATA+TEXT Section errechnet. Ich nehme einfach mal an das jedem klar ist 
das die Symbole etc. sowieso dazu gehören und es deshalb in den 
Beiträgen nicht expliziert erwähnt wurde.

Nun gut... Laut dieser Kalkulation und laut meiner Ausgabe durch "size" 
(binutils) sollte mein Programm ca. 500 Kb groß sein. Das kommt auch 
hin, denn ich verwende sehr viele constante Tabellen sowie große 
Arrays/Structs die eine Menge Speicher schlucken. Die Text Section ist 
ca. 70 Kb groß, der Rest ist Data. Das passt. Sowie ich es verstehe 
sollte ich hierfür 500KB ROM/FLASH benötigen. Mein Startup code kopiert 
dann beim hochlaufen die data section ins RAM um.

So jetzt die Preisfrage; Wenn ich mir mit den Binutils (objcopy -O 
binary ...) ein Binary erzeugen lasse ist dieses ca. 76Kb groß. Und 
eigentlich sollte das doch quasi ein "laufähiges Image" meines 
Programmes sein. Zummindest funktioniert alles wenn ich es mit einem 
Bootloader lade und VectorTable remappe... aber das ist jetzt erstmal 
egal.

Ich frage mich jetzt nur was da los ist. Ich vermute jetzt einfach mal 
das die text Section 1:1 in dem Binary abgebildet ist die data section 
aber nicht. Also ein Array der Größe 100x32 Bit belegt nicht 100x32 Bit, 
sondern befindet sich im Binary nur als Information das ein Array der 
Größe 100x32 im Ram an Position xyzabc (legt der Linker fest) liegt.


Ich hoffe einer kann meine Welt gerade rücken! Denn ich bin gerade etwas 
verwirrt.

Ach und noch am Rande, wenn ich mir ein HEX file aus dem .elf erzeuge 
ist dieses 200KB groß. Ich will eigentlich nur wissen wieviel ROM/Flash 
ich auf meinem Target braucht, bzw. wieviel Platz ich noch habe...

:)

von Klaus W. (mfgkw)


Lesenswert?

Nicht initialisierte Variablen (oder evtl. nur mit 0
initialisierte) müssen ja nicht 1:1 in deinem Image liegen
bzw. im ROM (BSS).
Ist das vielleicht der Teil, der dir fehlt?

von Rainer K. (Gast)


Lesenswert?

Hmm ja, also wenn es so ist dass eine nicht initialisierte Variable die 
erst zur Laufzeit gefüllt wird (z.B. Array in dem die letzten 100 
Temperatur Sensorwerte gespeichert werden) nicht den vollen Speicher im 
ROM belegt, ist alles klar. (Beispiel von meinem ersten Post 100x32 Bit 
Array...)

Hier steht Beitrag "avr-size: Wie groß ist das Programm denn nun wirklich?" das ROM Verbraucht 
= text + data section ist. Wenn ich dich richtig verstehe stimmt das 
also nicht.

von Klaus W. (mfgkw)


Lesenswert?

Ich weiß nicht, wie das bei AVR-gcc gemacht ist, ich kenne
es nur von anderen Systemen.
Aber ich gehe davon aus, daß es hier ähnlich ist.

Es gibt zumindest die Segmente TEXT, DATA und BSS.
TEXT enthält Programmcode.
DATA die initialisierten globalen und statischen Variablen.
BSS die nicht initialisierten globalen und statischen.

Nur TEXT und DATA belegen Platz im Image bzw. im ROM,
für BSS ist im Image nur die Größe angegeben und erst beim
Start wird dann entsprechend RAM belegt.

Teilweise ist es dann noch feiner unterteilt (z.B. .rodata und
.data für konstante und variable Daten), das tut hier aber nichts
zur Sache.

Alle nichtstatischen lokalen (automatische) Variablen
gehören sowieso nicht dazu, weil sie ja erst zur Laufzeit
im Stack landen.

Zu deinem Link sehe ich jetzt irgendwie keinen Widerspruch?

von Rainer K. (Gast)


Lesenswert?

Stimmt nicht initialisierte Variablen liegen in der BSS section und 
werden zur Laufzeit ins RAM initialisiert. Dann verstehe ich jetzt aber 
nicht warum die Werte die mir der GCC bzw die Binutils für die Sections 
ausspucken komplett falsch sind. Kann ja nicht sein das Text + Data 
section 500KB groß sind, ein erzeugtes binary dann aber nur 70-80 Kbyte.

von Andreas B. (Gast)


Lesenswert?

Wie wäre es, mal die tatsächliche Ausgabe von size oder objdump -h zu 
posten?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.