En compilant un fichier C trivial avec les drapeaux que vous avez fournis, entre gcc-4.5 et gcc-4.6 , et en utilisant objdump -h pour examiner la sortie, il semble que le .eh_frame la section est introduite dans gcc-4.6 .
Le ld le script que vous avez fourni ne s'occupe pas de cette section, et il devrait probablement le faire. Vous pouvez utiliser strip -R .eh_frame -R .eh_frame_hdr pour supprimer cette section et d'autres des fichiers objets avant la liaison.
Quoi qu'il en soit, puisque l'éditeur de liens est le même pour les deux versions de gcc, objdump -h sur les fichiers objets indiquera la différence qui cause ce problème.
Existe-t-il un argument de ligne de commande qui désactivera une fonctionnalité susceptible de produire des sections plus grandes
Oui :si vous vous souciez de la taille, vous devriez construire avec -Os . Le -O3 permet explicitement des optimisations qui pourraient conduire à une taille de code plus grande. Étant donné que le chargeur de démarrage s'exécute une fois , en utilisant -O3 car c'est presque certainement faux.
Modifier :
"L'optimisation de l'assemblage n'a pas de sens...
... et d'autres objets ici..."
Est tout de ton code en assembleur ? Si tel est le cas, le niveau d'optimisation n'a en effet aucun sens, mais vous devriez alors pouvoir simplement comparer la sortie de readelf -S vga_pm.S.o construit avec les deux compilateurs, et voir exactement quel les sections sont différentes.
Mais il semble plus probable que certains de vos objets ne le soient pas en assemblage, auquel cas la différence entre -O3 et -Os sera assez significatif.
GCC ajoute des sections de débogage indésirables à sa sortie binaire (utilisez objdump -h <file> pour les voir), j'ai l'habitude de mettre ceux que je ne veux pas dans un /DISCARD/ rule dans mes scripts ld pour s'en débarrasser :
/DISCARD/ : {
*(.debug_*)
*(.note*)
*(.indent)
*(.comment)
*(.stab)
*(.stabstr)
*(.eh_frame)
}