![]() |
Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Liste der Anhänge anzeigen (Anzahl: 2)
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? |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
|
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
Edit: Hast du mal die resultierenden Binaries statt der .map Dateien verglichen? |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
Zitat:
![]() |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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). |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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? |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
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. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Äh, seit Ihr Euch sicher, dass der Compiler das Problem verursacht und nicht der Linker?
|
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
Zitat:
@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: ![]() |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Das beschrieben Verhalten habe ich bisher auf allen Maschinen und mit allen Delphis (Delphi 6..Delphi 10.1) beobachtet.
|
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
wenn sich LLVM (MSBuild) auch noch dazwischen hängt. |
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
War da nicht neulich ein Bug im 64-Bit Compiler bei dem IdeFixPack. Wo kein deterministischer Code erzeugt wurde ?
|
AW: Warum ergibt zwei mal kompileren keine identischen .exe-Dateien?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:42 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz