GCC: Leeres Programm == 23202 Bytes?

test.c:

int main()
{
    return 0;
}

Ich habe keine Flags verwendet (ich bin ein Neuling bei gcc), nur den Befehl:

gcc test.c

Ich habe die neueste verwendet TDM-Build von GCC auf win32. Die resultierende ausführbare Datei ist fast 23 KB groß, viel zu groß für ein leeres Programm.

Wie kann ich die Größe der ausführbaren Datei reduzieren?

Folgen Sie nicht seinen Vorschlägen, aber lesen Sie zur Unterhaltung diese Geschichte’ über das Erstellen der kleinstmöglichen ELF-Binärdatei.

Wie kann ich seine Größe reduzieren?

• Tu es nicht. Du verschwendest nur deine Zeit.
• Verwenden Sie das Flag -s, um Symbole zu entfernen (gcc -s)

Standardmäßig sind einige Standardbibliotheken (z. B. C-Runtime) mit Ihrer ausführbaren Datei verknüpft. Schlüssel auschecken --nostdlib --nostartfiles --nodefaultlib für Details. Verknüpfungsmöglichkeiten beschrieben hier.

Für ein echtes Programm ist die zweite Option, es zu versuchen OptimierungsmöglichkeitenzB -Os (auf Größe optimieren).

Aufgeben. Unter x86-Linux erzeugt gcc 4.3.2 eine 5K-Binärdatei. Aber warte! Das ist mit dynamischer Verlinkung! Das statisch verknüpfte Binärdatei ist über ein halbes Megabyte: 516K. Entspannen Sie sich und lernen Sie, mit dem Aufblähen zu leben.

Und sie sagten, Modula-3 würde wegen einer 200.000-Hello-World-Binärdatei niemals irgendwo hingehen!

Falls Sie sich fragen, was los ist, die Gnu C-Bibliothek ist so strukturiert, dass sie bestimmte Funktionen enthält, unabhängig davon, ob Ihr Programm davon abhängt oder nicht. Zu diesen Funktionen gehören Kleinigkeiten wie malloc und free, dlopen, etwas String-Verarbeitung und vieles mehr ein Kübel voll Dinge, die mit Locales und Internationalisierung zu tun zu haben scheinen, obwohl ich keine relevanten Manpages finden kann.

Das Erstellen kleiner ausführbarer Dateien für Programme, die minimale Dienste erfordern, ist nicht ein Gestaltungsziel für glibc. Um fair zu sein, war es das auch nicht ein Designziel für jedes Laufzeitsystem, mit dem ich je gearbeitet habe (ungefähr ein halbes Dutzend).

Wenn Ihr Code nichts tut, ist es überhaupt fair, dass der Compiler trotzdem eine ausführbare Datei erstellt? 😉

Nun, unter Windows hätte jede ausführbare Datei immer noch eine Größe, obwohl sie angemessen klein sein kann. Mit dem alten MS-DOS-System würde eine vollständige Do-Nothing-Anwendung nur ein paar Bytes umfassen. (Ich denke, vier Bytes, um den 21-Stunden-Interrupt zum Schließen des Programms zu verwenden.) Andererseits wurden diese Anwendungen direkt in den Speicher geladen. Als das EXE-Format populärer wurde, änderten sich die Dinge ein wenig. Ausführbare Dateien hatten jetzt zusätzliche Informationen über den Prozess selbst, wie die Verschiebung von Code- und Datensegmenten sowie einige Prüfsummen und Versionsinformationen. Die Einführung von Windows fügte dem Format einen weiteren Header hinzu, um MS-DOS mitzuteilen, dass es die ausführbare Datei nicht ausführen konnte, da sie unter Windows ausgeführt werden musste. Und Windows würde es ohne Probleme erkennen. Natürlich wurde das ausführbare Format auch um Ressourceninformationen wie Bitmaps, Icons und Dialogformulare und vieles mehr erweitert.

Eine ausführbare Do-Nothing-Datei wäre heutzutage zwischen 4 und 8 Kilobyte groß, abhängig von Ihrem Compiler und jeder Methode, die Sie verwendet haben, um ihre Größe zu reduzieren. Es wäre bei einer Größe, bei der UPX tatsächlich zu größeren ausführbaren Dateien führen würde! Möglicherweise werden zusätzliche Bytes in Ihrer ausführbaren Datei hinzugefügt, weil Sie Ihrem Code bestimmte Bibliotheken hinzugefügt haben. Insbesondere Bibliotheken mit initialisierten Daten oder Ressourcen werden eine beträchtliche Menge an Bytes hinzufügen. Das Hinzufügen von Debug-Informationen erhöht auch die Größe der ausführbaren Datei.

Aber während dies alles eine nette Übung zum Reduzieren der Größe ist, könnten Sie sich fragen, ob es praktisch ist, sich einfach weiterhin Gedanken über das Aufblähen von Anwendungen zu machen. Moderne Festplatten teilen Dateien in Segmente auf, und bei wirklich großen Festplatten wäre der Unterschied sehr gering. Der Aufwand, der erforderlich wäre, um die Größe so klein wie möglich zu halten, verlangsamt jedoch die Entwicklungsgeschwindigkeit, es sei denn, Sie sind ein erfahrener Entwickler, der an diese Optimierungen gewöhnt ist. Diese Art von Optimierungen verbessern die Leistung in der Regel nicht, und angesichts des durchschnittlichen Speicherplatzes der meisten Systeme sehe ich nicht ein, warum dies praktisch wäre. (Trotzdem optimiere ich meinen eigenen Code auf ähnliche Weise, aber andererseits habe ich Erfahrung mit diesen Optimierungen.)

Interessiert an EXE-Header? Es beginnt mit den Buchstaben MZ, für „Mark Zbikowski“. Der erste Teil ist der MS-DOS-Header im alten Stil für ausführbare Dateien und wird als Stub für MS-DOS verwendet, der besagt, dass das Programm ist nicht eine ausführbare MS-DOS-Datei. (In der Binärdatei finden Sie den Text “Dieses Programm kann nicht im DOS-Modus ausgeführt werden.”, was im Grunde alles ist, was es tut: diese Nachricht anzeigen. Als nächstes kommt der PE-Header, den Windows erkennt und anstelle von MS-DOS verwendet Header Es beginnt mit den Buchstaben PE für Portable Executable. Nach diesem zweiten Header befindet sich die ausführbare Datei selbst, die in mehrere Code- und Datenblöcke unterteilt ist. Der Header enthält spezielle Neuzuordnungstabellen, die dem Betriebssystem mitteilen, wo ein bestimmter Block geladen werden soll. Und wenn Sie dies in Grenzen halten können, kann die endgültige ausführbare Datei kleiner als 4 KB sein, aber 90 % wären dann Header-Informationen und keine Funktionalität.

Ich mag übrigens die DJGPP FAQ darauf eingegangen vor vielen vielen Jahren:

Im Allgemeinen ist es bedeutungslos, die Codegröße anhand der Größe von „Hallo“-Programmen zu beurteilen, da solche Programme hauptsächlich aus dem Startcode bestehen. … Der größte Teil der Leistung all dieser Funktionen wird in “Hello”-Programmen verschwendet. Es hat keinen Sinn, den ganzen Code auszuführen, nur um eine 15-Byte-Zeichenfolge auszugeben und zu beenden.

Was ist der Zweck dieser Übung?

Selbst bei einer so niedrigen Programmiersprache wie C müssen noch viele Einstellungen vorgenommen werden, bevor main aufgerufen werden kann. Ein Teil dieses Setups wird vom Loader gehandhabt (der bestimmte Informationen benötigt), ein Teil wird vom Code gehandhabt, der main aufruft. Und dann gibt es wahrscheinlich ein bisschen Bibliothekscode, den jedes normale Programm haben müsste. Zumindest gibt es wahrscheinlich Verweise auf die Standardbibliotheken, wenn sie in DLLs enthalten sind.

Die Untersuchung der binären Größe des leeren Programms ist an und für sich eine wertlose Übung. Es sagt dir nichts. Wenn Sie etwas über die Codegröße lernen möchten, versuchen Sie, nicht leere (und vorzugsweise nicht triviale) Programme zu schreiben. Vergleichen Sie Programme, die Standardbibliotheken verwenden, mit Programmen, die alles selbst erledigen.

Wenn Sie wirklich wissen wollen, was in dieser Binärdatei vor sich geht (und warum sie so groß ist), dann finden Sie das ausführbare Format heraus, besorgen Sie sich ein Binär-Dump-Tool und nehmen Sie das Ding auseinander.