Durch Kompilieren einer trivialen C-Datei mit den von Ihnen bereitgestellten Flags zwischen gcc-4.5 und gcc-4.6 , und verwenden Sie objdump -h Um die Ausgabe zu untersuchen, scheint es, dass .eh_frame Abschnitt wird in gcc-4.6 eingeführt .
Die ld Das von Ihnen bereitgestellte Skript kümmert sich nicht um diesen Abschnitt, und das sollte es wahrscheinlich. Sie können strip -R .eh_frame -R .eh_frame_hdr verwenden diesen Abschnitt und andere vor dem Verknüpfen aus den Objektdateien zu entfernen.
Wie auch immer, da der Linker für beide gcc-Versionen gleich ist, objdump -h in den Objektdateien wird auf den Unterschied hinweisen, der dieses Problem verursacht.
Gibt es ein Befehlszeilenargument, das eine Funktion ausschaltet, die größere Abschnitte erzeugen kann
Ja:Wenn Ihnen die Größe wichtig ist, sollten Sie mit -Os bauen . Die -O3 aktiviert explizit Optimierungen, die zu einer größeren Codegröße führen könnten. Da der Bootloader einmal ausgeführt wird , mit -O3 denn es ist mit ziemlicher Sicherheit falsch.
Bearbeiten:
"Optimierung in der Montage ist sinnlos ...
... und andere Objekte hier ..."
Ist alles Ihres Codes in Assembler? Wenn ja, ist die Optimierungsstufe tatsächlich bedeutungslos, aber dann sollten Sie einfach die Ausgabe von readelf -S vga_pm.S.o vergleichen können mit beiden Compilern gebaut, und sehen Sie genau welche Abschnitte sind unterschiedlich.
Aber es scheint wahrscheinlicher, dass einige Ihrer Objekte nicht sind in Assembler, in diesem Fall der Unterschied zwischen -O3 und -Os wird sehr aussagekräftig sein.
GCC fügt seiner Binärausgabe einige unerwünschte Debug-Abschnitte hinzu (verwenden Sie objdump -h <file> um sie zu sehen), lege ich normalerweise diejenigen, die ich nicht möchte, in /DISCARD/ Regel in meinen ld-Skripten, um sie loszuwerden:
/DISCARD/ : {
*(.debug_*)
*(.note*)
*(.indent)
*(.comment)
*(.stab)
*(.stabstr)
*(.eh_frame)
}