Welche Teile der Codebasis machen Binärdateien groß?

Ich habe Code für einen Simulator erstellt und versuche jetzt, die kostenlose Toolchain von TI zu verwenden, um auf ein Ziel mit 64 KB NVRAM zu kompilieren. Der Compiler behauptet, dass mein Code etwa 34 KB über das ROM hinausgeht:

(...) msp430-elf/bin/ld: region `ROM' overflowed by 33716 bytes

Eine andere Zeile besagt, dass es nicht passen kann .text Feld in seinen zugewiesenen Raum. Ich kann nicht glauben, dass meine Ergänzungen insgesamt 34 KB groß sind, geschweige denn, dass die Binärdateien um diesen Betrag überlaufen.

• Die .o-Dateien, die mein Code dem Projekt hinzugefügt hat, sind ein kleiner Bruchteil (200 KB der 1,9 MB) des gesamten Projekts, und ich habe viele Komponenten herausgenommen, die ursprünglich im Projekt enthalten waren.
• Ich übergebe bereits den Compiler -Os -s Flaggen.
• Der neue Code enthält Zeichenfolgenliterale mit einem Wert von etwa 100 Zeichen.
• Mein Code verwendet viele math.h Funktionen (tatsächlich ist es der einzige Teil, der Fließkommaarithmetik ausführt), rufen Sie auf strtodund rufen Sie an sprintf

Gibt es Tools oder Methoden, um herauszufinden, warum die Binärdateien so groß sind?

GNU binutils hat Werkzeuge, die Ihnen helfen, die Größe jedes Symbols oder nur jeder Objektdatei zu bestimmen.

Schau mal rein size zum Beispiel: https://manpages.debian.org/jessie/binutils/size.1.en.html

nm ist auch einen Versuch wert, da es die Größe jedes Symbols im Objektcode anzeigen kann: https://manpages.debian.org/jessie/binutils/nm.1.en.html

Sorgfältige Überprüfung der Ausgabe von size und nm gibt Ihnen eine Intuition dafür, was viel Platz einnimmt und was nicht.

Wisse das printf, sprintf und viele der komplexeren Bibliotheksfunktionen können oft einige kB zusätzliches ROM beanspruchen.

Gleitkommaunterstützung mit Soft-Floats bläht den Code im Vergleich zur Verwendung von Hard-Float auf, dh die Verwendung von Software-Emulation vs. Hardware-Anweisungen zur Handhabung von Gleitkommazahlen.

Manchmal fügt der Compiler eine erstaunliche Menge an Aufblähen hinzu 🙂

Ich hatte auch einmal Speicherprobleme mit einem winzigen MSP430-Controller. Die TI-Toolchain verknüpft große Bibliotheken mit Ihrer Binärdatei, wenn negative Werte möglich sind oder Gleitkommazahlen verwendet werden. In meinem Fall waren es etwa 10% – 20% der gesamten Speichernutzung.

Das kostenlose Code Composer Studio von TI bietet eine sehr leistungsfähige Speichervisualisierung (Ansicht -> Speicherzuweisung).

Was mir sehr geholfen hat, war das Ändern des Initialisierungsmodells in den Linker-Einstellungen und andere Optimierungsoptionen. Ich arbeite derzeit nicht mit einem MSP430-Controller, daher kann ich Ihnen keine Details mehr sagen.

Es gibt auch AMAP, eine kleine und einfache GUI zum Anzeigen von .map-Dateien: http://www.sikorskiy.net/prj/amap/

Es wäre schön gewesen, ein kdirstat-ähnliches Tool zu haben, mit dem Sie Symbolgrößen visuell vergleichen können.

Obwohl es keine direkte Antwort auf die Frage war, habe ich am Ende die CORDIC-Implementierung von Voidware verwendet, um die Verwendung der großen Funktionen in zu vermeiden <math.h>: https://github.com/enthdegree/cordic_wrapped