Si le même code est construit à des moments différents avec GCC, le binaire résultant aura des contenus différents. Ok, je ne suis pas sauvage à 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 binaire avec une taille différente d'une construction antérieure (d'environ 1900 octets).
Quelqu'un a-t-il une idée de ce qui peut causer l'une de ces situations? Est-ce une sorte de problème elfe? Y a-t-il des outils là-bas (autre que LDD) qui peuvent être utilisés pour décharger des matières binaires pour voir ce qui est différent?
Merci d'avance.
7 Réponses :
Un exemple reproductible aiderait:
Les drapeaux du compilateur sont la première chose qui me vint à l'esprit. Surtout quelque chose comme --o.
Ceci a été une sorte d'a été Demandé avant , et la réponse est que le L'état interne du compilateur peut bien être différent sur différentes pistes du compilateur, ce qui peut entraîner une émission différente de code et ayant ainsi une taille différente.
Avant que les proches-singes ne soient heureux à ce sujet, je devrais indiquer que cette question consistait à obtenir des exe différents lorsqu'ils sont compilés sur différentes plates-formes (Windows aromatisées). Cette question consiste à obtenir des exe différents sur la même plate-forme avec le même compilateur.
... Cela étant dit, la réponse que vous avez donnée est en effet juste un bien ici.
Eh bien, les plates-formes sont censées être identiques. (Tout est construit des serveurs de construction dédiés). Donc, ce que nous essayons de comprendre est où cela a mal tourné.
Veuillez lire les deux postes - probablement rien n'a mal passé. Le compilateur peut éventuellement être dans différents états pour différentes exécutions sur la même machine, selon ce qui se passe d'autre.
D'accord. Très probablement la seule chose qui a «mal tourné» est la facture et les attentes de CO sur la manière dont les compilateurs se comportent.
Bien personnellement mon l'attente est que les compilateurs se comportent de manière déterministe, du moins en termes de production produite.
objdump est probablement le programme que vous recherchez pour vider le contenu des fichiers binaires.
objdump -h vous montrera les sections et leurs tailles. Vous devriez donc pouvoir voir où se passe la variation de la taille et puis explore davantage pour voir pourquoi.
Les compilateurs DEC VMS avaient l'habitude de le faire aussi. La raison en est que l'optimiseur pourrait faire un meilleur travail, plus il a dû travailler de RAM. Évidemment, il est très difficile d'avoir la même quantité de RAM gratuite disponible chaque fois que vous compilez.
Je me souviens à l'époque, certaines personnes ont été consteries par cela. C'était particulièrement le cas pour les personnes qui ont aimé vérifier les changements de source en diffentant les fichiers binaires résultants. Mon conseil, alors comme maintenant est de le remettre. Sources que vous pouvez "diff". Pour les fichiers binaires, la seule garantie est que les deux exécutables compilés des mêmes fichiers source feront ce que vous leur avez dit de faire.
Je pense qu'il est assez important que lorsque vous donnez au compilateur le même code source et les mêmes paramètres de construction, il émise toujours exactement le même exécutable, octet-forum d'octet. Sinon, s'il y a un bug dans l'optimiseur, vous risquez de vous retrouver avec des constructions de "fonctionnement" et de "non", basées uniquement sur la quantité de RAM qui se produisait librement pour le moment où l'exécutable a été construite .... Vraiment un cauchemar à déboguer! Même si le compilateur était exempt de bug, certaines de vos constructions seront plus rapides que d'autres, malgré le code source étant identique dans tous les cas.
Vous voudrez peut-être cela, mais comme Ted et moi-même avons souligné, vous ne pouvez pas l'avoir.
Soins Pour fournir une référence indiquant que GCC a ce comportement brisé, car c'est ce que la question de l'OP est à propos?
En plus du compilateur, vous devez vérifier les bibliothèques standard que vous associez. Vérifiez leur version et vérifiez qu'ils n'ont pas changé.
Une raison possible d'une différence de taille entre des constructions autrement identiques est qu'il peut y avoir des informations de taille variable stockées dans le binaire. Quelques exemples:
__ __ macro. Il est possible que cela puisse faire cela à ses propres fins qui n'ont rien à voir avec aucune de ces choses. Si la construction se produit sur différentes machines avec même une structure de répertoires légèrement différente, cela peut rendre compte des différences dans le binaire.
- De même pour la date / heure de la construction, je m'attendais à ce que ceux-ci se retrouvent dans le binaire beaucoup moins souvent (mais que je sais?). S'il s'agissait d'un facteur contributif, vous verriez une taille différente, même des constructions identiques sur la même machine, juste à des moments d'Enuogh différents.
Ces choses bouchent vers les différences dans l'état de la machine de construction, Comme Neil Butterworth a souligné .
J'ai réussi à trier les choses, du moins à ma satisfaction et je voulais passer ce que j'ai trouvé.
Utilisation de LOAWE, (LOIERF -A -W) J'ai créé un contenu de la liste de rapports des deux bâtiments et les comparé (en utilisant au-delà de la comparaison). Cela a montré que quelques symboles supplémentaires étaient tirés de Boost Libs.
LO et voici, nous étions en fait construisant une version différente d'une bibliothèque à charge et nous ne l'avons pas réalisé. Pas de mal fait dans ce cas, mais il est bon de savoir ce qui se passe dans votre exécutable.
Merci à tous pour les réponses réfléchies.