Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?

[himitsu]

Erstmal steht die CompileTime im PE-Header und die ist naturgemäß niemals gleich,
also egal was danach noch passiert, die Datei kann nie 100% identisch sein.

Eventuell arbeitet der Compiler auch nicht ganz statisch und optimiert manchmal so und manchmal so.

[SneakyBagels]

Zitat:

Eventuell arbeitet der Compiler auch nicht ganz statisch und optimiert manchmal so und manchmal so.

Das kann durchaus sein denn ich hatte mit XE8 oder Tokyo, weiß nicht mehr welches, bereits das Problem, dass eine gewisse Funktion mal funktioniert hat und mal nicht.

[himitsu]

Der Optimierer "sollte" aber nicht die Funktion verändern.
Also das Programm arbeitet eigentlich immer gleich, egal ob und wie optimiert wurde.

Außnahmen sind Sonderfälle, wo gewisse Eigenarten geziehlt ausgenutzt werden, wie z.B. absichtliche Integerüberläufe bei Hashfunktionen und Verschlüsselungen, welche dann abrauchen, wenn man die Bereichsprüfung aktiviert und bei dem Code das nicht beachtet wurde.

[Zacherl]

Zitat von himitsu:

Eventuell arbeitet der Compiler auch nicht ganz statisch und optimiert manchmal so und manchmal so.

Höchst unwahrscheinlich, dass der Compiler bei gleichem Quelltext nicht deterministisch auch den gleichen Code erzeugt.

Edit: Hast du mal die resultierenden Binaries statt der .map Dateien verglichen?

[Wosi]

Zitat von Zacherl:

Zitat von himitsu:

Eventuell arbeitet der Compiler auch nicht ganz statisch und optimiert manchmal so und manchmal so.

Höchst unwahrscheinlich, dass der Compiler bei gleichem Quelltext nicht deterministisch auch den gleichen Code erzeugt.

Das wäre nicht das erste mal:

Zitat:

After some research I must say that the 10 Seattle’s Win64 compiler’s generated code isn’t deterministic anymore (same input doesn’t generate the same output). It’s like the compiler uses the Random function to allocate CPU registers, so it could be an uninitialized variable somewhere in the compiler. The Win32 compiler and the XE8 and older Win64 compilers aren’t affected by this. So this is a regression bug for 10 Seattle.

http://andy.jgknet.de/blog/2015/10/i...-the-compiler/

[Namenloser]

Könnte durchaus sein, dass für so Probleme wie Registerallokation stochastische Algorithmen eingesetzt werden. Ist aber schon blöd, dass nicht jedes mal der gleiche RandSeed verwendet wird.

Eine weitere Ursache, die ich mir vorstellen könnte, wäre Parallelisierung (eventuell werden unabhängige Teile des Codes parallel kompiliert und je nachdem welcher Thread zuerst fertig wird, landet mal der eine oder der andere Teil früher in der Exe).

[hoika]

Hallo,
da es hier um eine Win32-Anwendung handelt, ist die Aussage zum 64-Bit-Compiler ohne Wert (?).

Ich habe folgende Vermutung:
Die Adressen sind relativ zu einer Startadresse.
Diese Startadresse wird wohl vom Compiler per Zufall gewählt,
um zu verhindern, dass sich Trojaner und andere freche Gesellen daran orientieren.

Oder verwechsel ich das mit Windows selber?

[Der schöne Günther]

Im Endeffekt interessieren mich ja mehr die Adressen (also map-Datei) als die exe selbst.

Grund: Ich hinterfragte den Aufrufstack von einem Crashlog beim Kunden. Die Vermutung war dass bei Release die falsche Map-Datei (.jdbg) beigelegt wurde und der Aufrufstack falsch ist. Ich wollte genau diese Version noch einmal neu builden und die enstandene Map-Datei vergleichen.

Sie sind völlig unterschiedlich. Das sagt aber leider nichts aus da die Map-Dateien anscheinend immer unterschiedlich sind. Doof.

[himitsu]

Die Startadresse ($Imagebase $00400000) ist eigentlisch statisch, da sie selten von den Entwicklern verändert wird.

Ob dann Windows zur Laufzeit alles reallociert, ist 'ne andere Geschichte.

[CCRDude]

Schaut euch doch mal die Screenshots an, statt zu spekulieren

Es geht nicht um den Timestamp im PE-Header (und selbst der war jahrelang statisch). Auch ASLR ist Betriebssystemsache und keine Aufgabe des Compilers. Und unterschiedliche Teile, die zuerst in der .exe landen, passen da genau so wenig zu. Parallelisierung müsste mehrere Threads für einzelne Methoden bedeuten, was ich mir nicht als effektiv vorstellen kann.

Es geht scheinbar in allen Fällen (in den Screenshots) um lediglich vier Byte, und zwischendurch pendeln die auch wieder zurück.
Zugegeben verwirrt Günther da mit "Sie sind völlig unterschiedlich" selber, denn "völlig" ist das wahrlich nicht

Ne Antwort habe ich auch nicht, da mein letztes Delphi XE (ja, noch ohne Zahl) war. Ist doch aber nicht soo schwer... zwei unterschiedliche Dateien nehmen, und zwei Funktionen am Wechsel zwischen Gleichlauf und Versatz disassemblieren und vergleichen, inwieweit die identisch sind, ob da ggfls. ein nop-Padding dazwischen ist... dann hätte der Compiler einfach Probleme mit dem Alignment.