Hallo Leute, wovon hängt der Inhalt eines durch den Compile und Link-Prozess erzeugtes Hex-Files (Motorola) ab? Konkret geht es darum, das ich ein Projekt von einem alten Build-Prozess der nur bis WinXP funktioniert hat auf einen neuen Stand gebracht habe. Das Kompilieren geht nun auch unter Win8, der Compiler ist der gleiche geblieben. Allerdings sind die dabei erzeugten Hex-Files unterschiedlich, zwar nicht gravierend; aber in einem Diff sichtbar. Deshalb meine Frage: Von welchen Dateien hängt ein Hex-File ab? Kann die Reihenfolge der Kompilierten und gelinkten Dateien eine Reihe spielen? Wie ist das mit der Relativen Anordnung der Dateien untereinander? Danke Patrick
Patrick L. schrieb: > Wie ist das mit der Relativen Anordnung der Dateien untereinander? Was meinst Du denn genau mit relativer Dateianordnung?
Es gibt ja auch Umwandlungsprogramme. Z.B. kannst Du mit dem Make-Befehl unterschiedliche Modi wählen, z.B. ob Du einen .hex-File haben willst. Du kannst auch z.B. einen .bin-File anwählen. Es gibt also manigfaltige Variationen des Make-Befehls. Die Frage ist ja - was willst Du denn damit machen? Möchtest Du ein Gerät mit dem hex-File flashen?
Patrick L. schrieb: > Von welchen Dateien hängt ein Hex-File ab? Von allen C/ASM Dateien und auch von Libraries. Übrigens gibt es Makros in C, mit denen das aktuelle Datum in einen String eincompiliert werden kann. > Kann die Reihenfolge der Kompilierten und gelinkten Dateien eine Reihe > spielen? Ja, insbesondere beim Linken. > Wie ist das mit der Relativen Anordnung der Dateien untereinander? Kommt auf den Linker an, manche können umsortieren.
Patrick L. schrieb: > wovon hängt der Inhalt eines durch den Compile und Link-Prozess > erzeugtes Hex-Files (Motorola) ab? s19? Die können am Anfang einen S0 Record enthalten, da schreibt objcopy den Dateinamen rein, z.B. "build/foobar.s19" Ansonsten disassembliere sie doch mal beide (mit objdump) und mach ein diff, dann siehst Du genau was anders ist: arm-none-eabi-objdump -D foobar.s19 -m arm -M force-thumb
Patrick L. schrieb: > Von welchen Dateien hängt ein Hex-File ab? Von der *.elf Datei aus der das Hex-File generiert wird. Die Darstellung des HEX-File ist nicht eindeutig. Jede Zeile beinhaltet Startcode Byte count Adresse Typ Datenfeld Prüfsumme Wenn ich jetzt 200 Byte Programmcode habe, kann ich das in 20 Zeilen mit je 10 Byte Aufsplittern oder in 10 mit je 20 Byte Ansonsten gibt es noch ein ähnliches Format von Motorola dort gilt aber das gleiche http://de.wikipedia.org/wiki/Intel_HEX http://de.wikipedia.org/wiki/S-Record (Motorola)
:
Bearbeitet durch User
Seidenschnabel schrieb: > Was meinst Du denn genau mit relativer Dateianordnung? Wenn man sich die Object-Dateien ansieht, dann sind teilweise noch Dateipfade oder Einbindungen (die sind im endgültigen Kompilat sicherlich weg) sichtbar. Jetzt die Frage ob die Namen der Ordner in denen sich die Dateien befinden einen Einfluss auf das Hex-File hat. Seidenschnabel schrieb: > Es gibt ja auch Umwandlungsprogramme. Z.B. kannst Du mit dem Make-Befehl > unterschiedliche Modi wählen, z.B. ob Du einen .hex-File haben willst. > Du kannst auch z.B. einen .bin-File anwählen. Es gibt also manigfaltige > Variationen des Make-Befehls. Ja, die Compile-Options und der Code ist gleich gelieben. Einzig die Umgebung hat sich von WinXP nach Win8 geändert. > Die Frage ist ja - was willst Du denn damit machen? Möchtest Du ein > Gerät mit dem hex-File flashen? Das Flashen ist nicht das Problem, ich möchte sicher gehen, dass der Code sich gleich verhält wie der alte Code. Also durch meine Portierung ein zu meinen alten Hex-File binärkompatibles neues Hex-File enstanden ist. Dann könnte ich sicher gehen, dass ich durch meine umstellung nicht übersehen / kaputt gemacht habe. Sicherlich wäre ein weiterer Ansatz die logisch Funktion des Codes zu überprüfen. Jim Meba schrieb: > Von allen C/ASM Dateien und auch von Libraries. > Übrigens gibt es Makros in C, mit denen das aktuelle Datum in einen > String > eincompiliert werden kann. > Ist bei meinem Code nicht der Fall. >> Kann die Reihenfolge der Kompilierten und gelinkten Dateien eine Reihe >> spielen? > > Ja, insbesondere beim Linken. > Ok, interessanter Aspekt >> Wie ist das mit der Relativen Anordnung der Dateien untereinander? > > Kommt auf den Linker an, manche können umsortieren. Ich benutze Tasking von Altium. Bernd K. schrieb: > Ansonsten disassembliere sie doch mal beide (mit objdump) und mach ein > diff, dann siehst Du genau was anders ist: > > arm-none-eabi-objdump -D foobar.s19 -m arm -M force-thumb Diff habe ich bereits gemacht, allerdings bis jetzt nur von der Hex-Files (S-REC). Nicht von der Disassembliat. Danke bis jetzt für die Antworten
Christian K. schrieb: > Von der *.elf Datei aus der das Hex-File generiert wird. > > Die Darstellung des HEX-File ist nicht eindeutig. > > Jede Zeile beinhaltet > Startcode > Byte count > Adresse > Typ > Datenfeld > Prüfsumme > > Wenn ich jetzt 200 Byte Programmcode habe, kann ich das in > 20 Zeilen mit je 10 Byte Aufsplittern > oder in 10 mit je 20 Byte Das ist ein Punkt. Aber ich geh jetzt mal davon aus, dass ein Linker deterministisch arbeitet und deshalb bei ansonsten gleichen Einstellungen und gleich Eingangsdaten auch die gleichen Ausgangsdaten erzeigen sollte. So ist zumindest bist jetzt mein Verständnis. Ich sag mal so, wenn ich heute ein Hex-File erzeuge und zwei Tage später noch eins; bei dem gleichen Projekt, ohne etwas zu ändern, kommen ja auch identische Dateien raus.
Du hast geschrieben, das der Quellcode von damals der gleiche ist, und die Compiler/Linker Einstellungen die Gleichen sind. Ist auch der gleiche Linker und Compiler (Version/Binary) der gleiche? Dadurch das der Linker die die Objektdateien in einer anderen Reihenfolge bearbeitet, können die gleichen Funktionen jetzt an anderen Adressen liegen. Des weiteren kann ich die Lektüre um die Verifikation des Truecrypt-Quellcodes empfehlen. Da wurde beschrieben das schon die Installation von Windows-Updates beim Compiler/Linker zu unterschiedlichen Binares geführt hat.
:
Bearbeitet durch User
Hallo Patrick, Du schreibst Du benutzt "Tasking" von Altium. Wir verwenden die Tasking TriCore Toolkette (und diverse andere). Speziell bei dieser Toolkette habe ich solche Probleme leider regelmässig. Neben den genannten wichtigen Punkten - genau gleiche Toolversion (davon gehe ich aus, wer so wie Du genau hinschaut hat das berücksichtigt) - identische Reihenfolge auf der Linker-Kommandozeile gibt es leider speziell bei dieser Toolkette noch andere Probleme mit der Reproduzierbarkeit. Patrick L. schrieb: > wenn ich heute ein Hex-File erzeuge und zwei Tage später > noch eins; bei dem gleichen Projekt, ohne etwas zu ändern, kommen ja > auch identische Dateien raus. Dies hatte ich auch gedacht bis wir den Tasking Linker kannten, definitiv ist dies bei uns leider nicht immer so, nur "fast immer" bzw. "fast gleich" . Wir haben hier tatsächlich den Fall, dass manchmal irgendwelche Zufallsmechanismen eine Rolle spielen. Je nach Toolversion ist es besser oder schlechter. Ich empfehle (und das ist kein Witz) mal mit den gleichen objects/libs viele male (1000+) den Linker aufzurufen und die Ergebnisse zu vergleichen... Bzw. wenn möglich die objects von XP auf Win8 zu linken und umgekehrt. Gruß, Erik
Patrick L. schrieb: > wovon hängt der Inhalt eines durch den Compile und Link-Prozess > erzeugtes Hex-Files (Motorola) ab? Das "Hex-File" ist üblicherweise eine bestimmte Schreibweise des Ergebnisses des Prozesses, ein Programm in einer beliebigen Sprache in der Maschinensprache des Zielsystems zu überführen und das Ergebnis des Prozesses wiederum in einer lesbaren Textdatei darzustellen. Logischerweise hängt also der Inhalt von mindestens vier Sachen ab: 1) Zielsystem 2) Programm 3) Code-Generator 4) Hexfile-Encoder > Kann die Reihenfolge der Kompilierten und gelinkten Dateien eine Reihe > spielen? Natürlich. > Wie ist das mit der Relativen Anordnung der Dateien untereinander? Ja klar, auch das kann Einfluß nehmen.
Christian K. schrieb: > Ist auch der gleiche Linker und Compiler (Version/Binary) der gleiche? Jap, Version ist auch gleich geblieben. Einzig Win8 ist ein 64-Bit Betriebsystem. > Dadurch das der Linker die die Objektdateien in einer anderen > Reihenfolge bearbeitet, können die gleichen Funktionen jetzt an anderen > Adressen liegen. Ja ok, ist einleuchtend. Erik L. schrieb: > Du schreibst Du benutzt "Tasking" von Altium. > Wir verwenden die Tasking TriCore Toolkette (und diverse andere). > Speziell bei dieser Toolkette habe ich solche Probleme leider > regelmässig. Ja ist auch ein TriCore-Chip für den ich das Hex-file erzeuge. > Neben den genannten wichtigen Punkten > - genau gleiche Toolversion (davon gehe ich aus, wer so wie Du genau > hinschaut hat das berücksichtigt) Jap, sollte alles passen wenn ich nichts übersehen habe. > - identische Reihenfolge auf der Linker-Kommandozeile Ja, da kann es möglicherweise unerscheide geben. Evtl. werde ich mal von Hand linken. Im Moment wird das über ein Makefile erledigt. > gibt es leider speziell bei dieser Toolkette noch andere Probleme mit > der Reproduzierbarkeit. Ok, gut wenn ich es nicht binärkompatibel hinkriege ist es auch nicht schlimm, dann schaue ich einfach ob ansonsten die Funktion gegeben ist. Da es sich bei dem portierten Code um einen Bootloader handelt, der als kritisch anzusehen ist will ich alle Zweifel ausschließen, dass ich da Murks beim portieren gemacht habe. Gerade weil der Bootloader auch an bestimmten Stellen im Speicher gewisse Variablen erwartet die über ein Memory Mapping festgelt worden sind.
Hallo, es ändert am Programmablauf nichts, wenn Programmteile, z.B. die Unterprogramme, an anderen Adressen liegen - der Linker kann die Unterprogramme speichern wie er sie vorfindet oder alphabetisch sortieren oder nach Grösse, das ändert nichts am Programmablauf. Nur Reset und bei vielen Prozessoren die Interruptprogramme müssen an festgelegten Adressen liegen. Es ist daher unwahrscheinlich, dass andere Tools ein binär gleiches Ergebnis erzeugen, es sei denn man erzwingt das selbst z.B. mit ABS-Befehlen. Bei C usw. kommt natürlich hinzu, dass auch die Libraries nicht gleich sind. Georg
Georg schrieb: > Hallo, > > es ändert am Programmablauf nichts, wenn Programmteile, z.B. die > Unterprogramme, an anderen Adressen liegen - der Linker kann die > Unterprogramme speichern wie er sie vorfindet oder alphabetisch > sortieren oder nach Grösse, das ändert nichts am Programmablauf. Ist mir klar, allerdings bin ich mir nicht 100% sicher ob ich alle Compiler und Linker-Optionen aus den alten Makefile richtig portiert habe. > Nur Reset und bei vielen Prozessoren die Interruptprogramme müssen an > festgelegten Adressen liegen. Ja, ist ja dann warscheinlich in dem *.lsl File definert und Prozessorabh. > Es ist daher unwahrscheinlich, dass andere > Tools ein binär gleiches Ergebnis erzeugen, es sei denn man erzwingt das > selbst z.B. mit ABS-Befehlen. Tools sind gleich geblieben. > Bei C usw. kommt natürlich hinzu, dass auch die Libraries nicht gleich > sind. > Alles gleich geblieben
Patrick L. schrieb: > Alles gleich geblieben Ja hast Du jetzt mal beide hex files disassembliert und ein diff der beiden Disassemblate gemacht? Dieses eine diff sagt wahrscheinlich mehr als tausend Spekulationen, vielleicht kann es Dir auch beweisen daß die beiden immer noch funktional identisch sind oder falls nicht gibt es vielleicht einen wertvollen Hinweis darauf warum es so ist wie es ist und wie man es eventuell wieder beheben könnte oder ob das überhaupt nötig ist. Alles andere ist pure Spekulation.
Hallo Patrick, wenn Du so weit bist dass Du nur noch "geringe" Unterschiede hast kann Dir das dissassemblieren vielleicht helfen, vielleicht reicht dann auch ein Blick in die zugehörigen .map-Files (hier sind die effektiven Linker-Optionen genannt) Falls es wirklich an der Toolkette liegen sollte: An die Open Issues ranzukommen ist derzeit etwas umständlich, neben Anfrage beim Support (Wartungsvertrag vorausgesetzt) könntest Du die readmes der Folgeversionen anschauen (Startpunkt http://www.tasking.com/support/tricore/) dann kommst Du auch hier vorbei: http://issues.tasking.com/?issueid=160-38240 http://issues.tasking.com/?issueid=160-38463 (das waren aber glaube ich nicht die einzigen zum Theman ...) Gruß Erik
:
Bearbeitet durch User
Also mal ein kleiner Zwischenstand. Den größten einfluss hat wohl die Reihenfolge unter der die Dateien zusammengelinkt werden. Ich habe es jetzt hinbekommen, dass sich die Map-Files fasst gleich sind. Laut Map-File sind zwei Object-Files kleiner geworden, warum das passiert ist untersuche ich noch. Call-Trace der Funktionen ist gleich geblieben; wenn auch teilweise in anderer Reihenfolge im Map-File vermerkt. Vermutlich haben sich durch die leicht größeren Object-Files auch die ein paar Speicher-Adressen geändert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.