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

[Der schöne Günther]

Vorwarnung: Ich kenne mich mit Compilern und was da alles im Hintergrund geschieht nicht aus.

Ich habe in einem Delphi-Projekt für Win32 die Erstellung von .map-Dateien aktiviert. Drücke ich zwei mal auf "Erzeugen" und vergleiche die erstellten Map-Dateien sind diese nicht identisch. Die Adressen unterschieden sich (siehe Bilder). Manchmal viel, manchmal wenig.

Warum ist das so?

[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.