bcc compilés binarys avec différentes tailles?

Si le même code est construit à différents moments w / gcc, le binary résultant aura un contenu différent. OK, je ne suis pas fou à ce sujet, mais c’est ce que c’est.

Cependant, j’ai récemment rencontré une situation où le même code, construit avec la même version de gcc, génère un binary de taille différente d’une version précédente (d’environ 1900 octets).

Quelqu’un a-t-il une idée de ce qui peut causer l’une ou l’autre de ces situations? Est-ce une question de type ELF? Existe-t-il des outils (autres que ldd) qui peuvent être utilisés pour vider le contenu des binarys pour voir ce qui est différent?

Merci d’avance.

objdump est probablement le programme que vous recherchez pour vider le contenu des binarys.

objdump -h va vous montrer les sections et leurs tailles, vous devriez donc être capable de voir où la taille change, et ensuite aller plus loin pour voir pourquoi.

J’ai réussi à régler les problèmes, du moins à ma satisfaction, et je voulais transmettre ce que j’avais trouvé.

Utiliser readelf, (readelf -a -W) J’ai créé un rapport répertoriant le contenu des deux versions et les comparant (en utilisant Beyond Compare). Cela montrait que quelques symboles supplémentaires étaient extraits des boost boosts.

En fait, nous construisions en fait une version différente d’une bibliothèque dépendante et ne l’avons pas réalisé. Pas de mal à faire dans ce cas, mais il est bon de savoir ce qui se passe dans votre exécutable.

Merci à tous pour vos réponses réfléchies.

Un exemple reproductible aiderait:

Utilisez-vous d’autres bibliothèques externes?
Vous reliez de manière statique ou dynamic?
Avez-vous changé des drapeaux comme -O ou -s?

Cela a été en quelque sorte demandé auparavant , et la réponse est que l’état interne du compilateur peut très bien être différent sur différentes exécutions du compilateur, ce qui peut entraîner l’émission de code différent et donc une taille différente.

Les compilateurs DEC VMS le faisaient aussi. La raison en est que l’optimiseur pourrait faire un meilleur travail avec plus de RAM libre avec laquelle il devait travailler. De toute évidence, il est très difficile d’avoir exactement la même quantité de mémoire vive disponible à chaque fois que vous comstackz.

Je me souviens que certaines personnes étaient consternées par cela. Ce fut particulièrement le cas pour les personnes qui aimaient vérifier les changements de source en différenciant les binarys résultants. Mon conseil alors comme maintenant est de le surmonter. Les sources que vous pouvez “diff”. Pour les binarys, la seule garantie est que les deux exécutables compilés à partir des mêmes fichiers source feront ce que vous leur avez demandé.

En plus du compilateur, vous devez vérifier les bibliothèques standard auxquelles vous vous connectez. Vérifiez leur version et vérifiez qu’elles n’ont pas changé.

Une des raisons possibles d’une différence de taille entre des constructions par ailleurs identiques est qu’il peut y avoir des informations de taille variable stockées dans le binary. Quelques exemples:

le compilateur peut mettre des informations de chemin / nom sur les fichiers invoqués dans la compilation, soit pour les informations de débogage, soit pour l’utilisation de la macro __FILE__ . Il est possible que cela le fasse pour ses propres objectives qui n’ont rien à voir avec aucune de ces choses. Si la génération se produit sur différentes machines avec une structure de répertoires légèrement différente, cela peut expliquer les différences entre les binarys.
de même pour la date / heure de la construction, même si je m’attendais à ce que celles-ci se retrouvent dans le binary beaucoup moins souvent (mais que sais-je?). Si cela était un facteur consortingbutif, vous verriez des tailles différentes même à partir de builds identiques sur la même machine, juste à des moments différents.

Comme l’a souligné Neil Butterworth, ces choses se résument à des différences dans l’état de la machine de construction.