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:

Zitat von himitsu (Beitrag 1375569)

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:

Zitat von Zacherl (Beitrag 1375574)

Zitat:

Zitat von himitsu (Beitrag 1375569)

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.

[Delphi-Laie]

Zitat:

Zitat von himitsu (Beitrag 1375569)

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

Das kann ja "irgendwie nicht ganz wahr sein".

Seit wann ist die Optimierung ein - salopp forumuliert - Glücksspiel?

Hat der Kunde nicht das Recht auf stete vollumfängliche Optimierung gemäß den eingestellten Optionen?

Wenigstens ein Compiler sollte verläßlich, genaugenommen determiniert arbeiten. Ansonsten muß man sich über die Ablehnung solcher Compilate für sicherheitskritische Bereiche nicht wundern.

[samso]

Äh, seit Ihr Euch sicher, dass der Compiler das Problem verursacht und nicht der Linker?

[Zacherl]

Zitat:

Zitat von Delphi-Laie (Beitrag 1375633)

Wenigstens ein Compiler sollte verläßlich, genaugenommen determiniert arbeiten. Ansonsten muß man sich über die Ablehnung solcher Compilate für sicherheitskritische Bereiche nicht wundern.

:thumb: Zumindest sollte ein solches Feature nicht standardmäßig aktiviert sein.

Zitat:

Zitat von samso (Beitrag 1375643)

Äh, seit Ihr Euch sicher, dass der Compiler das Problem verursacht und nicht der Linker?

Auch der Linker sollte standardmäßig deterministisch arbeiten.

@Günther:
Compilierst du eventuell auf einer Maschine mit Skylake CPU? Hier wurde ja ein CPU-Bug gefunden, der scheinbar speziell durch Compiler oft ausgelöst wird:
https://www.golem.de/news/cpu-bug-wi...06-128662.html

[samso]

Das beschrieben Verhalten habe ich bisher auf allen Maschinen und mit allen Delphis (Delphi 6..Delphi 10.1) beobachtet.

[himitsu]

Zitat:

Zitat von samso (Beitrag 1375660)

Das beschrieben Verhalten habe ich bisher auf allen Maschinen und mit allen Delphis (Delphi 6..Delphi 10.1) beobachtet.

Und es wird zukünftig noch viel besser,
wenn sich LLVM (MSBuild) auch noch dazwischen hängt.

[Rollo62]

War da nicht neulich ein Bug im 64-Bit Compiler bei dem IdeFixPack. Wo kein deterministischer Code erzeugt wurde ?

[Delphi-Laie]

Zitat:

Zitat von Rollo62 (Beitrag 1375809)

War da nicht neulich ein Bug im 64-Bit Compiler bei dem IdeFixPack. Wo kein deterministischer Code erzeugt wurde ?

Was Du meinst, ist, daß der Compiler und/oder Linker (jedenfalls das monierte Programm) nicht determiniert bzw. deterministisch arbeitet und deshalb nicht immer den gleichen Code erzeugt. Das erstellte Programm selbst kann wiederum determiniert sein.