PatentDe  


Dokumentenidentifikation DE102004022183B4 13.04.2006
Titel Verfahren zum Ändern von Programmobjektcode bei Quelltextänderungen
Anmelder Fujitsu Siemens Computers GmbH, 80807 München, DE
Erfinder Engelbrecht, Ullrich, 81739 München, DE
Vertreter Epping Hermann Fischer, Patentanwaltsgesellschaft mbH, 80339 München
DE-Anmeldedatum 05.05.2004
DE-Aktenzeichen 102004022183
Offenlegungstag 01.12.2005
Veröffentlichungstag der Patenterteilung 13.04.2006
Veröffentlichungstag im Patentblatt 13.04.2006
IPC-Hauptklasse G06F 9/445(2006.01)A, F, I, 20051017, B, H, DE
IPC-Nebenklasse G06F 9/45(2006.01)A, L, I, 20051017, B, H, DE   

Beschreibung[de]

Die Erfindung beschreibt ein Verfahren zum Erstellen einer Korrekturanweisung zur Änderung von Programmobjektcode eines auf der Ebene der Quelltexte modular aufgebauten Programms bei Änderungen im Quelltext eines Moduls gemäß dem Oberbegriff des Anspruchs 1.

Ausführbare Computerprogramme bestehen aus einer binären Sequenz von Maschinencodebefehlen, dem Programmobjektcode. Entsprechend der Syntax der Maschinencodebefehle ist der Programmobjektcode prozessorabhängig.

Da die Maschinencodebefehle in ihrer binären Repräsentation sehr unanschaulich sind, wird Programmobjektcode üblicherweise auf eine der drei im folgenden beschriebenen Arten erstellt.

Zu jedem Maschinencodebefehl wird ein mnemonisches Kürzel als Synonym definiert, wobei die Zuordnung in beide Richtungen eindeutig ist. Das Programm wird dann als lesbarer Quelltext in dieser Synonymsprache geschrieben und anschließend in den ausführbaren Programmobjektcode übersetzt. Die Synonymsprache und auch das Programm, das zum Übersetzen benutzt wird, werden als Assembler, der Vorgang als Assemblieren bezeichnet. In Assembler geschriebene Programme sind schnell und speichereffizient, erfordern allerdings hohen Programmieraufwand – insbesondere wenn sie für einen Prozessor geschrieben werden, der nur über einen sehr eingeschränkten Befehlssatz verfügt.

Eine weitere Möglichkeit, Programmobjektcode zu erzeugen besteht darin, das Programm in der Synonymsprache eines Prozessortyps zu schreiben und von einem sogenannten Cross-Assembler in Maschinencodebefehle für einen anderen Prozessortyp zu übersetzen. Cross-Assembler ermöglichen damit auch, auf der Basis eines Quellcodes ausführbare Programmobjektcode für verschiedene Prozessortypen zu erzeugen. Sie erleichtern die Programmierung insofern, dass die Synonymsprache eines Prozessors, der über einen weiten Befehlssatz verfügt, benutzt werden kann.

Bei der dritten Methode bedient sich der Programmierer einer sogenannten Hochsprache, wie Fortran, Pascal, C usw., die unabhängig vom Prozessortyp ist und komplexe Anweisungen zulässt. Das Übersetzungsprogramm wird in diesem Fall üblicherweise Compiler genannt. Der Programmieraufwand ist in diesem Fall am geringsten, der erzeugte Programmobjektcode ist jedoch weniger speichereffizient und weniger gut geschwindigkeitsoptimiert.

Im Rahmen dieser Anmeldung umfasst der Begriff Compiler sowohl Assembler, Cross-Assembler sowie Compiler im obigen Sinne. Quelltext bezeichnet im folgenden eine Folge von Anweisungen entweder in Assembler oder einer Hochsprache. Als Objektcode wird die beim Übersetzen des Quellcodes vom Compiler entstehende Sequenz an Maschinencodebefehlen bezeichnet.

Komplexe Programme werden üblicherweise nicht als ein Quelltext-Dokument erstellt, sondern statt dessen in mehrere kleine funktionelle Untereinheiten, Module genannt, unterteilt. Module, die nicht programmspezifisch, sondern von universellerem Nutzen für verschiedenste Programme sind, werden häufig in Form einer Zusammenstellung (Bibliothek) abgelegt. Zum Erstellen des Programmobjektcodes werden die Quelltexte zunächst modulweise vom Compiler in Objektcode, dann Modulobjektcode genannt, übersetzt. Ein zweites Programm, der sogenannte Linker, fügt dann den Modulobjektcode aller von dem Programm benutzten Module zum Programmobjektcode zusammen. Zusätzlich wird vom Linker eine Tabelle eingefügt, in der der Name der benutzten Module sowie die relative Adresse innerhalb des Programmobjektcodes, unter der diese Module zu finden sind, gespeichert ist. Diese Information ist wichtig, falls Sprünge innerhalb des Programms in ein bestimmtes Modul notwendig sind oder falls Zugriff auf Daten erfolgen soll, die in den Modulen gespeichert sind.

Der Vorteil des modularen Konzepts liegt neben der größeren Übersichtlichkeit darin, dass bei Änderungen nur der Quelltext der geänderten Module neu übersetzt werden muss, nicht der Quelltext des gesamten Programms. Allerdings muss in jedem Fall das gesamte Programm neu durch Linken zusammengefügt werden. Auch dieses kann noch sehr aufwändig sein, insbesondere bei komplexen Programmen mit sehr vielen Modulen, wie es z.B. Betriebssysteme sind. Hinzu kommt, dass Änderungen im Quelltext einzelner Module typischerweise vom Programmierer durchgeführt werden, das Linken allerdings unter Umständen beim Anwender geschehen muss, da viele benutzerspezifische oder konfigurationsabhängige Module im Programm vorhanden sind. Für den Benutzer ist dieser Prozess nicht nur zeitaufwändig, sondern birgt darüber hinaus die Gefahr, dass durch Eingeben falscher Parameter beim Linken ein nicht funktionstüchtiger Programmobjektcode erstellt wird.

Eine Möglichkeit, um vom Anwender zumindest kleine Änderungen durchführen zu lassen, besteht darin, eine Korrekturanweisung in Form einer Datei zu erstellen, in der einzelne Bytes oder eine Folge von Bytes, die im Objektcode eines bestimmten Moduls zu tauschen ist, gelistet sind. Diese Korrekturanweisung wird von einem beim Benutzer vorhandenen Programm ausgewertet, das die entsprechenden Austauschoperationen am Programmobjektcode durchführt. Diese Vorgehensweise ist zwar für den Anwender unkompliziert durchzuführen, aber nur bei minimalen Änderungen praktikabel.

Eine Weiterbildung eines solchen Verfahrens ist beispielsweise aus der Druckschrift US 6,634,026 B1 bekannt. Das dort offenbarte Verfahren ist geeignet, eine für eine bestimmte Version eines Programms manuell ausgearbeitete Änderung eines Programmobjektcodes ohne weiteren Aufwand auf andere Versionen des Programms zu übertragen.

Die Korrekturanweisung gibt Änderungen auf Ebene des Objektcodes an. Sehr kleine Änderungen am Objektcode wie z.B. falsche Wertezuweisung oder eine falsche Sprungadresse lassen sich auf dieser Ebene vom Programmierer manuell korrigieren. Weiterreichende Änderungen lassen sich auf dieser Ebene so gut wie nicht durchführen, sondern werden von den Programmentwicklern auf Ebene des Quelltextes ausgeführt. Selbst kleine Änderungen im Quelltext führen aber auf schwer vorhersehbare Art zu komplexen Änderungen im Objektcode. Die zur Anpassung des Programmobjektcodes notwendigen Korrekturanweisungen sind nur mühevoll anzugeben, wenn der Objektcode durch einen Assembler erzeugt wird. Wenn der Quellcode aber durch einen Cross-Assembler oder Hochsprachencompiler erzeugt wird, ist es für den Programmierer praktisch nicht mehr möglich, Korrekturanweisungen manuell anzugeben.

Aus der Druckschrift US 6,594,822 B1 ist ein Verfahren bekannt, bei dem eine Korrekturanweisung anhand eines Vergleichs von ursprünglichem Objektcode und korrigiertem Objektcode erstellt wird, wobei der korrigierte Objektcode aus der Übersetzung eines geänderten Quelltextes stammt. Dadurch, dass sich die Struktur von Objektcode bereits bei kleinen Modifikationen des Quelltextes stark verändern kann, erfolgt bei diesem Verfahren der Vergleich von ursprünglichem und korrigiertem Objektcode nicht direkt, sondern anhand vorausgehender aufwändiger Strukturanalysen mittels sogenannter „reduced program dependency graphs".

Ein ähnliches Verfahren ist auch aus der Druckschrift JP 10091423 A bekannt. Bei diesem Verfahren wird ein geänderter Programmquelltext mit dem ursprüngliche Programmquelltext verglichen. Die Unterschiede werden ermittelt und zusammen mit dem ursprüngliche Programmobjektcode einem Compiler zugeführt, der einen korrigierten Objektcode und eine Korrekturanweisung erstellt. Auch hier ist eine Analyse des ursprüngliche Programmobjektcodes vonnöten, um die Unterschiede einarbeiten zu können.

Aufgabe der Erfindung ist daher, ein Verfahren zu beschreiben, durch das nach Änderung des Quelltextes eines oder mehrerer Module eines modular aufgebauten Programms eine Korrekturanweisung, gemäß der ein neuer Programmobjektcode durch Veränderung des ursprünglichen Programmobjektcodes erzeugt wird, erstellt wird, ohne dass eine Analyse der Struktur des Programmobjektcodes erforderlich ist.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zum Erstellen einer Korrekturanweisung nach dem kennzeichnenden Teil des Anspruchs 1 gelöst.

Das erfindungsgemäße Verfahren basiert auf der Grundidee, dass Änderungen im Quelltext dem Compiler in Form von Änderungsanweisungen mitgeteilt werden. Dadurch kann vom Compiler zu einem geänderten Modulquelltext ein neuer Modulobjektcode erzeugt werden, der bei korrekt geänderter Funktionalität den höchsten Grad an Kongruenz mit dem alten Modulobjektcode aufweist.

Vorteilhafterweise kann dann eine Korrekturanweisung für den Programmobjektcode durch den byte-weisen Vergleich vom geänderten mit dem ursprünglichen Modulobjektcode generiert werden.

In einer weiteren Ausführungsform kann die Korrekturanweisung alternativ während des Übersetzens vom Compiler erstellt werden.

In einer günstigen Ausgestaltung des Verfahrens besteht die Änderungsanweisung aus der Angabe von wegfallenden Abschnitten, die aus dem ursprünglichen Modulquelltext entfernt werden, um den geänderten Modulquelltext zu erhalten und/oder aus der Angabe von hinzukommenden Abschnitten und deren Positionen, die zu dem ursprünglichen Modulquelltext hinzugefügt werden, um den geänderten Modulquelltext zu erhalten. Weiterhin ist bevorzugt, diese Änderungsanweisung und den ursprünglichen Modulquelltext in einem neuen Modulquelltext anzugeben, wobei der neue Modulquelltext aus dem ursprünglichen Modulquelltext und hinzukommenden Abschnitten besteht und zusätzlich wegfallende bzw. hinzukommende Abschnitte durch Schlüsselwörter gekennzeichnet sind.

Weitere Einzelheiten und mögliche Ausführungsformen des Verfahrens sind in den Unteransprüchen angegeben.

Das erfindungsgemäße Verfahren wird im folgenden anhand von Ausführungsbeispielen mit Hilfe der Figuren näher erläutert.

Es zeigen:

1 eine schematische Repräsentation des Verfahrens zum Erstellen und Ändern von Programmobjektcode gemäß dem Stand der Technik,

2 eine schematische Repräsentation eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens,

3 ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens,

4 ein Flussdiagramm eines Abschnitts des erfindungsgemäßen Verfahrens in einem Ausführungsbeispiel,

5 einen Auszug aus einem Quelltext und einem von einem Assembler gemäß dem Flussdiagramm in 4 erstellten Modulobjektcodes und

6 einen Auszug eines von einem Cross-Assembler erstellten Modulobjektcodes zu dem in 5 angegebenen Quelltext.

In 1 ist die Erzeugung und Änderung eines Programmobjektcodes eines komplexen, modular aufgebauten Programms gemäß dem Stand der Technik dargestellt. Ein ursprünglicher Modulquelltext 10 wird von einem Compiler 40 in einen ursprünglichen Modulobjektcode 20 übersetzt. Dieser ursprüngliche Modulobjektcode 20 wird mit Objektcode weiterer Module 23 durch einen Linker 41 zu dem ursprünglichen Programmobjektcode 30 zusammengefügt. Zusätzlich wird vom Linker 41 eine Tabelle mit Einbindeinformationen 35 erstellt, in der angegeben ist, an welcher Stelle im Programmobjektcode sich der Objektcode bestimmter Module befindet.

Änderungen im Quelltext, die von dem ursprünglichen Modulquelltext 10 zu einem geänderten Modulquelltext 11 führen, können typischerweise nur in der Weise berücksichtigt werden, dass der geänderte Modulquelltext 11 auf analoge Weise vom Compiler 40 in einen geänderten Modulobjektcode 21 übersetzt wird, welcher wiederum mit dem Objektcode weiterer Module 23 vom Linker 41 zu einem geänderten Programmobjektcode 31 zusammengefügt wird.

Alternativ kann das Ändern von Programmobjektcode auch durch das manuelle Erstellen 42 einer Korrekturanweisung 33 erfolgen. Diese Korrekturanweisung 33 wird einem Korrekturprogramm 43 mitgeteilt, das byte-weise Änderungen am ursprünglichen Programmobjektcode 30 vornimmt und so zu einem korrigierten Programmobjektcode 32 kommt. Die Korrekturanweisung 33 besteht aus einer Folge von Einträgen 34, die den Namen des Moduls, einen neuen Wert und der Position innerhalb des Modulobjektcodes, an dem dieser neue Wert gespeichert werden soll, enthalten. Anhand der Einbindeinformation 35 kennt das Korrekturprogramm 43 die Position des entsprechenden Moduls innerhalb des Programmobjektcodes. Damit kann die Position des zu ändernden wertes im ursprünglichen Programmobjektcode 30 berechnet und der Wert entsprechend der Korrekturanweisung 34 geändert werden, um aus dem ursprünglichen Programmobjektcode 30 einen korrigierten Programmobjektcode 32 zu erzeugen. Dieser Weg ist natürlich nur sinnvoll, wenn es möglich ist, dass der korrigierte Programmobjektcode 32 dieselbe Funktionalität hat, wie ein geänderter Programmobjektcode 31, der aus Übersetzen des geänderten Modulquelltextes 11 durch den Compiler 40 und anschließendes Zusammenfügen des geänderten Modulobjektcode 21 mit dem Objektcode weiterer Module 23 durch den Linker 41, entstanden wäre.

Das manuelle Erstellen der Korrekturanweisung 33, die auf der Ebene von Objektcode arbeitet, bedingt, dass nur kleinste Änderungen innerhalb des Programmobjektcodes durchgeführt werden können. Dazu zählen beispielsweise das Austauschen von fehlerhaften Konstanten oder Wertezuweisung oder das Ändern einzelner Sprungadressen. Komplexere Änderungen, die beispielsweise in die Ablaufstruktur eines Programms eingreifen, sind auf der Abstraktionsebene von Maschinencodebefehlen fast nicht durchführbar. Insbesondere gilt dies, wenn der Quelltext mit Hilfe eines Cross-Assemblers oder Hochsprachencompilers übersetzt wird.

In 2 ist an einem Ausführungsbeispiel schematisch dargestellt, wie die Korrekturanweisung 33 mit ihren Einträgen 34 nach dem erfindungsgemäßen Verfahren erstellt wird. Neben dem ursprünglichen Modulquelltext 10 wird dem Compiler 40 eine Änderungsanweisung 12 bereitgestellt. Aus dem ursprünglichen Quelltext 10 und der Änderungsanweisung 12 erzeugt der Compiler 40 einen korrigierten Modulobjektcode 22. Dieser korrigierte Modulobjektcode 22 wird zusammen mit dem ursprünglichen Modulobjektcode 20, der durch Übersetzen des ursprünglichen Modulquelltextes 10 entstanden ist, einem Vergleicher 44 bereitgestellt. Der ursprüngliche Modulobjektcode 20 wird mit dem korrigierten Modulobjektcode 22 byte-weise verglichen. Bei Abweichungen wird die Position des abweichenden Bytes relativ zum Beginn des ursprünglichen Modulobjektcodes 20 und der Wert des sich unterscheidenden Bytes des korrigierten Modulobjektcodes 22 ermittelt. Die ermittelte Position und der Wert sowie der Name des Moduls werden dann als ein Eintrag 34 zu der Korrekturanweisung 33 hinzugefügt. Falls mehrerer abweichende Bytes hintereinander folgen, kann alternativ nur die Position des ersten Bytes und eine Folge von Werten sowie der Name des Moduls als ein Eintrag 34 zu der Korrekturanweisung 33 hinzugefügt werden.

Es ist möglich, dass eine Folge von neuen Werten eine Adresse innerhalb des Objektcodes eines weiteren Moduls 23 angeben. In dem Fall wird auch der Name des anderen Moduls sowie die Adresse der Korrekturanweisung 33 als Eintrag 34 hinzugefügt.

Gemäß den Informationen aus den Einträgen 34 der Korrekturanweisung 33 erstellt das Korrekturprogramm 43 dann unter Zuhilfenahme der Einbindeinformation 35 aus dem ursprünglichen Programmobjektcode 30 den korrigierten Programmobjektcode 32.

Im erfindungsgemäßen Verfahren wird dem Compiler 40 nicht ein geänderter Modulquelltext 11 bereitgestellt, sondern der ursprüngliche Modulquelltext 10 und die Änderungsanweisung 12. Diese Änderungsanweisung 12 beschreibt in einem vorgegebenen Format, auf welche Weise aus dem ursprünglichen Modulquelltext 10 der geänderte Modulquelltext 11 entsteht. Beispielsweise kann angegeben werden, welche Abschnitte beim Übergang vom ursprünglichen Modulquelltext 10 zum geänderten Modulquelltext 11 wegfallen sollen, und welche Abschnitte hinzukommen sollen.

Änderungen an einem Quelltext werden in der Regel von dieser Form sein. In den seltensten Fällen werden die Änderungen so grundlegender Natur sein, dass sich nicht viele Teilstücke oder Abschnitte des ursprünglichen Quelltextes 10 auch im geänderten Modulquelltext 11 wiederfinden. Beim Vorgang des Assemblierens führen gleiche Abschnitte im Modulquelltext auch notwendigerweise zu gleichen Abschnitten im Modulobjektcode, beim Crossassemblieren oder beim Compilen aus einer Hochsprache ist dies nicht mehr zwingend der Fall, kann beim Einsatz eines geeigneten Compiler 40 aber erreicht werden.

Wird der geänderte Modulquelltext 11 jedoch vom einem Compiler 40 im üblichen Verfahren übersetzt, befinden sich eventuell gleiche Abschnitte des ursprünglichen Modulobjektcodes 20 und des geänderten Modulobjektcodes 21 bedingt durch eine unterschiedliche Länge von hinzukommenden oder wegfallenden Abschnitten an unterschiedlichen Positionen innerhalb der Dateien wieder. Trotz prinzipiell vorhandener gleicher Abschnitte unterscheiden sich der ursprüngliche Modulobjektcode 20 und der geänderte Modulobjektcode 21 damit in einem byte-weisen Vergleich grundlegend. wird dem Compiler 40 dagegen statt des geänderten Modulquelltextes 11 der ursprüngliche Modulquelltext 10 und Änderungsanweisungen 12 mitgeteilt, sind gleichbleibende Abschnitte im Modulquelltext gekennzeichnet, und können vom Compiler 40 in ihrer Entsprechung als Objektcode an der selben Stelle im Modulobjektcode positioniert werden, an der sie im ursprünglichen Modulobjektcode 20 zu finden waren. Der so entstandene Modulobjektcode weist die gleiche Funktionalität wie der geänderte Modulobjektcode 21 auf, unterscheidet sich in einem byte-weisen Vergleich vom ursprünglichen Modulobjektcode 20 aber so wenig wie möglich. Er wird zur Unterscheidung daher korrigierter Modulobjektcode 22 genannt.

Dieser korrigierte Modulobjektcode 22 wird in dem Vergleicher 44 byte-weise mit dem ursprünglichen Modulobjektcode 20 verglichen. Aus dem Vergleich werden die Einträge 34 der Korrekturanweisung 33 erstellt, die in bekannter Art vom Korrekturprogramm 43 ausgewertet werden.

Das erfindungsgemäße Verfahren kann dann garantiert ausgeführt werden, wenn die Länge aller Objektcodeabschnitte von wegfallenden Abschnitten des Quelltextes die Länge aller Objektcodeabschnitte von hinzukommenden Abschnitten des Quelltextes übersteigt. Im anderen Fall ist nur das Erstellen eines geänderten Programmobjektcodes 31 gemäß dem Stand der Technik durch Übersetzen des geänderten Modulquelltextes 11 und Zusammenfügen der Objektcodes aller Module durch den Linker 41 möglich. Ein Ausführungsbeispiel des Verfahrens zum Erstellen des korrigierten Modulobjektcodes 22 wird weiter unten in 4 anhand eines Flussdiagramms im Detail erläutert.

In 3 ist eine weitere mögliche Ausgestaltung des erfindungsgemäßen Verfahrens dargestellt. Der ursprüngliche Modulquelltext 10 ist zusammen mit den Änderungsanweisungen 12 sowie Schlüsselwörtern 14, die wegfallende und hinzukommende Abschnitte kennzeichnen, als ein modifizierter Modulquelltext 13 angegeben. Der Compiler 40 erstellt aus diesem modifizierten Modulquelltext 13 sowohl den korrigierten Modulobjektcode 22 als auch gleichzeitig die Korrekturanweisung 33, die in bekannter Art weiterverarbeitet wird.

Das Zusammenfügen von Änderungsanweisung 12 samt Schlüsselwörtern 14 mit dem ursprünglichen Modulquelltext 10 zu einem modifizierten Modulquelltext 13 stellt für den Anwender eine bequeme Art des Einfügens von Änderung in den ursprünglichen Modulquelltext 10 dar. Die Schlüsselwörter 14 fungieren als sogenannte Präcompilerdirektiven. Der Aufbau des modifizierten Modulquelltextes 13 ist dabei kompatibel mit einer üblichen Betriebsweise von Compilern, bei der über Präprozessordirektiven Einfluss auf den Ablauf des Übersetzungsvorgangs genommen werden kann.

Der Compiler 40 ist in diesem Ausführungsbeispiel so ausgelegt, dass immer dann, wenn dem korrigierten Modulobjektcode 22 Objektabschnitte hinzufügt werden, die im ursprünglichen Modulobjektcode 20 nicht vorkommen, bzw. wenn im korrigierten Modulobjektcode 22 Abschnitte nicht vorkommen, die im ursprünglichen Modulobjektcode 20 enthalten waren, diese Änderungen in Form von Einträgen 34 direkt auch in die Korrekturanweisung 33 geschrieben werden. Falls das erfindungsgemäße Verfahren auf Grund des Umfangs der eingefügten Abschnitte nicht erfolgreich durchgeführt werden kann, kann in diesem Ausführungsbeispiel der Compiler 40 so ausgelegt sein, dass nach Ausgabe eines entsprechenden Hinweises an den Benutzer keine Korrekturanweisung 33 erstellt wird und statt des korrigierten Modulobjektcodes 22 dann automatisch der geänderte Modulobjektcode 21 erstellt wird.

4 zeigt in Form eines Flussdiagramms ein Ausführungsbeispiel für den Teil des Verfahrens, nach dem aus dem modifizierten Modulquelltext 13 der korrigierte Modulobjektcode 22 erstellt werden kann.

Zu Beginn des Verfahrens wird ein Speicherbereich definiert, der Modulobjektcode aufnehmen kann und ein Zeiger definiert, der auf die aktuelle Position des Übersetzungsprozesses im modifizierten Modulquelltext 13 zeigt. Der Speicherbereich für den Modulobjektcode sei zu Beginn leer und die Übersetzungsposition wird auf den Anfang des Quelltextes gesetzt. Die Bezeichnung der folgenden Schritte folgt dem Patentanspruch 4.

Im Schritt a wird der modifizierte Modulquelltext 13 vom Compiler 40 übersetzt, bis das Schlüsselwort 14 „REPOLD" oder das Ende des modifizierte Modulquelltextes 13 erreicht sind. Der in diesem Schritt a entstandene Objektcode wird im Schritt b dem Speicherbereich für Modulobjektcode zugefügt. Da dieser zu Beginn des Verfahrens als leerer Speicherbereich definiert wurde, entspricht dieser Schritt dem Speichern des Objektcodes. In Schritt c wird der modifizierte Modulquelltextes 13 weiter übersetzt bis zum Schlüsselwort 14 „REPNEW" bzw. bis zum Ende des modifizierte Modulquelltextes 13. Die Länge des in diesem Schritt entstandenen Objektcodes wird als erste Länge gespeichert, der Objektcode selber verworfen. Falls die Übersetzungsposition bereits in Schritt a das Ende des modifizierten Modulquelltextes 13 erreicht hatte, wird die erste Länge den Wert Null haben. Im nächsten Schritt d wird der modifizierte Modulquelltext 13 vom Compiler weiter übersetzt, bis das Schlüsselwort 14 „REPEND" auftaucht oder das Ende des modifizierte Modulquelltextes 13 erreicht ist. Die Länge des in diesem Schritt entstandenen Objektcodes wird als zweite Länge gespeichert, der Objektcode in diesem Fall nicht verworfen. Analog zur ersten Länge wird die zweite Länge den Wert Null haben, falls die Übersetzungsposition in einem der vorangehenden Schritte a oder c bereits das Ende des modifizierte Modulquelltextes 13 erreicht hatte. In der danach folgenden Abfrage wird ermittelt, ob die erste Länge kleiner ist als die zweite Länge. Falls nicht, bedeutet das, dass der Objektcode des hinzukommenden Abschnitts länger ist als der Objektcode des wegfallenden Abschnitts. Damit kann das erfindungsgemäße Verfahren nicht erfolgreich durchgeführt werden und wird abgebrochen. In einem nächsten Schritt wird untersucht, ob die Länge des Objektcodes kleiner ist als die erste Länge. Wenn das der Fall ist, wird in Schritt e der Objektcode um eine Null-Operation (NOOP) ergänzt. Abfrage und eventuelles Ergänzen einer Null-Operation wird so oft durchgeführt, bis die Länge des Objektcodes genau gleich der ersten Länge ist. Im dann folgenden Schritt g wird der Objektcode einschließlich der angehängten Null-Operation dem Speicherbereich für Modulobjektcode hinzugefügt. Für den Fall, dass bereits in Schritt a oder c die Übersetzungsposition das Ende des modifizierten Modulquelltextes 13 erreicht hatte, wird der Objektcode in Schritt g leer sein und somit keine Änderung am Speicherbereich für Modulobjektcode hervorrufen. Im folgenden Schritt wird erneut überprüft, ob die Übersetzungsposition am Ende des modifizierten Modulquelltextes 13 angelangt ist. Wenn ja, wird das Verfahren erfolgreich beendet und der im Verlauf des Verfahrens im Speicherbereich für Modulobjektcode angesammelte Objektcode als korrigierter Modulobjektcode 22 gespeichert. Falls die Übersetzungsposition noch nicht am Ende des modifizierten Modulquelltextes 13 angelangt ist, wird das Verfahren mit Ausnahme des allerersten Schrittes, in dem der Speicherbereich für Modulobjektcode definiert und geleert wurde, wiederholt. Ein in einem zweiten oder eventuellen weiteren Durchläufen im Schritt a entstehendender Objektcode wird damit an den bereits bestehenden Modulobjektcode angehängt.

Das hier vorgestellte Verfahren wird abgebrochen, wenn der Objektcode eines wegfallenden Abschnitts kürzer ist als der Objektcode des direkt darauf folgenden hinzukommenden Abschnitts. Auch in diesem Fall könnte es jedoch sein, dass der Objektcode aller wegfallenden Abschnitte aufsummiert länger ist als der Objektcode aller hinzukommenden Abschnitte. Das Verfahren könnte in der Weise ausgestaltet sein, dass die Abbruchbedingung diesen Fall berücksichtigt.

In 3 wurde ein Verfahren vorgestellt, bei dem die Korrekturanweisung 33 gleich während des Übersetzens vom Compiler 40 erstellt wird. Im gezeigten Flussdiagramm kann diese Funktion im Schritt g implementiert werden. Die in Schritt g hinzugefügten Objektcodeabschnitte entsprechen gerade den Abschnitten des korrigierten Modulobjektcodes 22, die sich von dem ursprünglichen Modulobjektcode 20 unterscheiden und können daher an dieser Stelle leicht in Form von Einträgen 34 in die Korrekturanweisung 33 übernommen werden.

5 verdeutlicht anhand eines Beispiels die Funktionsweise des erfindungsgemäßen Verfahrens für einen Assembler als Compiler. Im oberen linken Teil ist ein Abschnitt des ursprünglichen Modulquelltextes 10 angegeben, der hier aus drei Assemblerbefehlen besteht. Im oberen rechten Abschnitt ist der modifizierte Modulquelltext 13 angegeben. Nach einem ersten Assemblerbefehl, der sich gegenüber dem ursprünglichen Modulquelltext 10 nicht geändert hat, deutet das Schlüsselwort 14 „REPOLD" den Beginn eines zu ersetzenden Abschnitts an. Im gezeigten Beispiel besteht der zu ersetzende Abschnitt aus lediglich einem Befehl. Das darauffolgende Schlüsselwort 14 „REPNEW" kennzeichnet den Beginn eines neu hinzukommenden Abschnitts, der in diesem Fall ebenfalls aus nur einem Befehl besteht und durch das Schlüsselwort 14 „REPEND" beendet wird. Der sich anschließende Teil des modifizierten Modulquelltextes 13 entspricht wieder dem ursprünglichen Modulquelltext 10.

Im unteren Teil von 5 sind auf der linken Seite der ursprüngliche Modulobjektcode 20, der durch Übersetzen des ursprünglichen Modulquelltextes 10 entstanden ist, und auf der rechten Seite der korrigierte Modulobjektcode 22, der nach dem erfindungsgemäßen Verfahren aus dem modifizierten Modulquelltext 13 entstanden ist. Zur Verdeutlichung sind ganz links die Hexadezimaladressen der entsprechenden Maschinencodebefehle als Position des Objektcodes innerhalb der entsprechenden Dateien angegeben. Ebenfalls zur Verdeutlichung sind die dem Objektcode entsprechenden Assemblerbefehle mit angegeben, die in dieser Form natürlich im Modulobjektcode nicht enthalten sind. Im korrigierten Modulobjektcode 22 ist zu sehen, dass die Maschinencoderepräsentation des hinzugekommenen Befehls eine Länge von 4 Byte aufweist, wobei ein Byte in der benutzten Kodierung jeweils zwei Hexadezimalzeichen aufnimmt. Der wegfallende Maschinencodebefehl hat hingegen im ursprünglichen Modulobjektcode 20 eine Länge von 6 Bytes hat. Entsprechend des Verfahrens nach 4 wurde der Längenunterschied durch das Einfügen von Null-Operationen ausgeglichen. In diesem Beispiel wurde genau eine Null-Operation eingefügt, da eine Null-Operation in der hier dargestellten Maschinencoderepräsentation eine Länge von 2 Byte hat.

Alle nachfolgenden Maschinencodebefehle befinden sich im korrigierten Modulobjektcode 22 an der gleichen Position innerhalb der Datei wie im ursprünglichen Modulobjektcode 20. Dadurch können zum einen durch einen byte-weisen Vergleich beider Modulobjektcodes Unterschiede schnell ausfindig gemacht werden, zum anderen ist sichergestellt, dass alle Einsprungadressen, die sich im weiteren Verlauf des Modulobjektcodes befinden, nach wie vor korrekt adressiert werden.

In 6 ist analog zur 5 die Erstellung des korrigierten Modulobjektcodes 22 anhand des erfindungsgemäßen Verfahrens durch einen Cross-Assembler dargestellt. Dem Beispiel liegt ebenfalls der Quelltext von 5 zugrunde. Aus dem ursprünglichen Modulobjektcode 20 auf der linken Seite ist ersichtlich, dass die Übertragung des einen wegfallenden Assemblerbefehls des ursprünglichen Modulquelltextes 10 zu insgesamt acht Maschinencodebefehlen, die jeweils 4 Byte lang sind, führt. Ein solcher Fall entsteht typischerweise, wenn Assemblerbefehle für einen Prozessor mit CISC-Architektur (Complex Instruction Set Computer) in den Maschinencode eines Prozessors mit RISC-Architektur (Reduced Instruction Set Computer) durch einen Cross-Assembler übersetzt wird. Im korrigierten Modulobjektcode 22 ist ersichtlich, dass der im modifizierten Modulquelltext 13 hinzugekommene Befehl durch einen einzigen, 4 Byte langen Maschinencodebefehl repräsentiert wird.

Entsprechend wurden vom Compiler 40 nach dem erfindungsgemäßen Verfahren sieben Null-Operationen eingefügt, die je ebenfalls eine Länge von 4 Byte aufweisen.

Beim Übersetzen von Quelltext durch einen Assembler gibt es eine umkehrbar eindeutige Beziehung zwischen dem Quelltext und dem Objektcode. Im Fall eines Cross-Assemblers oder beim Compilieren von Quelltext einer Hochsprache gibt es diese Eindeutigkeit nicht mehr. Der Compiler hat beim Übersetzungsvorgang gewisse Freiheitsgrade, die zur Optimierung des erzeugten Objektcodes genutzt werden. Es kann beispielsweise sein, dass beim Cross-Assemblieren Maschinencodebefehle für einen Prozessor erzeugt werden, der eine größere Anzahl von Registern besitzt als von den Assemblerbefehlen adressiert werden können. Die nicht adressierbaren Register können dann vom Compiler zur Speicherung von Zwischenergebnissen eingesetzt werden. Solche Optimierungsschritte müssen beim Abarbeiten des modifizierten Modulquelltextes 13 vom Compiler 40 berücksichtigt werden. Es kann beispielsweise notwendig sein, dass am Ende von hinzukommenden Modulcodeabschnitten die in diesen Abschnitten gemachten Änderungen an Registern, die zuvor zur Zwischenspeicherung von Ergebnissen zur Optimierung eingesetzt wurden, wieder rückgängig gemacht werden. Ähnliches kann auftreten, wenn durch den Cross-Assembler Maschinencodebefehle für einen Prozessor erzeugt werden, der über einen breiteren Adress- oder Datenbus verfügt, der durch die Assemblersprache des Modulquelltextes repräsentiert wird. In diesem Fall muss ein korrektes Be- oder Entladen von Adressierungs- oder Datenregistern am Beginn und am Ende von hinzukommenden Modulcodeabschnitten berücksichtigt werden.

10ursprünglicher Modulquelltext 11geänderter Modulquelltext 12Änderungsanweisung 13modifizierter Modulquelltext 14Schlüsselwörter 20ursprünglicher Modulobjektcode 21geänderter Modulobjektcode 22korrigierter Modulobjektcode 23Objektcode weiterer Module 30ursprünglicher Programmobjektcode 31geänderter Programmobjektcode 32korrigierter Programmobjektcode 33Korrekturanweisung 34Eintrag der Korrekturanweisung 35Einbindeinformation 40Compiler 41Linker 42manuelles Erstellen der Korrekturanweisung 43Korrekturprogramm 44Vergleicher

Anspruch[de]
  1. Verfahren zum Erstellen einer Korrekturanweisung (33) zur Änderung von Programmobjektcode eines auf der Ebene der Quelltexte modular aufgebauten Programms bei Änderungen im Quelltext eines Moduls, wobei

    – ein ursprünglicher Modulquelltext (10),

    – ein durch Übersetzen des ursprünglichen Modulquelltextes (10) durch einen Compiler (40) entstandener ursprünglicher Modulobjektcode (20),

    – Objektcode weiterer Module (23),

    – ein ursprünglicher Programmobjektcode (30), der durch Zusammenfügen des Modulobjektcodes (20) mit dem Objektcode weiterer Module (23) durch einen Linker (41) entstanden ist,

    – eine Änderungsanweisung (12), deren Anwendung auf den ursprünglichen Modulquelltext (10) einen geänderten Modulquelltext (11) ergibt,

    vorhanden sind, dadurch gekennzeichnet, dass

    – unter unmittelbarer Verwendung des ursprünglichen Modulquelltextes (10) und der Änderungsanweisung (12) ein korrigierter Modulobjektcode (22) derart erzeugt wird, dass sich Objektcodeabschnitte, die Abschnitten des ursprünglichen Modulquelltextes (10) entsprechen, die nicht von den Änderungsanweisungen (12) betroffen sind, an der selben relativen Position innerhalb des korrigierten Modulobjektcodes (22) befinden, an der sie sich auch im ursprünglichen Modulobjektcode (20) befinden und dass der korrigierte Modulobjektcode (22) die gleiche Länge aufweist, wie der ursprüngliche Modulobjektcode (20) und

    – aus einem Vergleich des ursprünglichen Modulobjektcodes (20) mit dem korrigierten Modulobjektcode (22) die Korrekturanweisung (33) erstellt wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Änderungsanweisungen (12)

    – aus der Angabe von wegfallenden Abschnitten bestehen, die aus dem ursprünglichen Modulquelltext entfernt werden, um den geänderten Modulquelltext (11) zu erhalten, und/oder

    – aus der Angabe von hinzukommenden Abschnitten und deren Position bestehen, die zu dem ursprünglichen Modulquelltext hinzugefügt werden, um den geänderten Modulquelltext (11) zu erhalten.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Änderungsanweisungen (12) in einem modifizierten Modulquelltext (13) angegeben sind, wobei der modifizierte Modulquelltext (13) aus dem ursprünglichen Modulquelltext (10) besteht und zusätzlich

    – in dem modifizierten Modulquelltext (13) die wegfallenden Abschnitte mit vorgegebenen Schlüsselwörtern (14) gekennzeichnet sind und gegebenenfalls

    – in dem modifizierten Modulquelltext (13) hinzukommende Abschnitte, die sich an wegfallende Abschnitte anschließen, eingefügt sind und die ebenfalls mit Schlüsselwörtern (14) gekennzeichnet sind.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der korrigierte Modulobjektcode (21) aus dem ursprünglichen Modulobjektcode (20) durch den Compiler (40) gebildet wird, indem

    a. der modifizierte Modulquelltext (13) bis zum Beginn des ersten bzw. des nächsten auftretenden wegfallenden Abschnitts in Objektcode übersetzt wird,

    b. der in Schritt a entstandene Objektcode als korrigierter Modulobjektcode (22) gespeichert wird,

    c. der modifizierte Modulquelltext (13) weiter bis zum Ende des wegfallenden Abschnitts in Objektcode übersetzt wird, und die Länge des in diesem Schritt entstandenen Objektcodes als erste Länge gespeichert wird,

    d. der modifizierte Modulquelltext (13) weiter bis zum Ende eines gegebenenfalls hinzukommenden Abschnitts in Objektcode übersetzt wird, und die Länge des in diesem Schritt entstandenen Objektcodes als zweite Länge gespeichert wird,

    e. ein Objektcodeabschnitt zusammengesetzt wird aus dem im Schritt d entstandenen Objektcode und so vielen Nulloperationen, bis die Länge des Objektcodeabschnitts der ersten Länge entspricht, falls die erste Länge größer oder gleich der zweiten Länge ist,

    f. das Verfahren mit einer Fehlermeldung abbricht, falls die erste Länge kleiner als die zweite Länge ist,

    g. der Objektcodeabschnitt an den korrigierten Modulobjektcode (22) angehängt wird,

    h. die Schritte a bis g wiederholt werden, falls weitere wegfallende Abschnitte im modifizierten Modulquelltext (13) vorhanden sind, wobei das Übersetzen an der zuvor erreichten Stelle im modifizierten Modulquelltext (13) fortgesetzt wird und der in Schritt a entstehende Objektcode im Schritt b an den korrigierten Modulobjektcode (22) angehängt wird, und

    der modifizierte Modulquelltext (13) von der zuvor erreichten Stelle an bis zu seinem Ende in Objektcode übersetzt wird, falls keine weiteren wegfallenden Abschnitte im modifizierten Modulquelltext (13) vorhanden sind, und der in diesem Schritt entstandene Objektcode an den geänderten Modulobjektcode (22) angehängt wird.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichent, dass die Korrekturanweisung (33) erstellt wird, indem

    – der ursprüngliche Modulobjektcode (20) mit dem korrigierten Modulobjektcode (22) byte-weise verglichen wird,

    – bei Abweichungen die Position relativ zum Beginn des ursprünglichen Modulobjektcodes (20) und der Wert des sich unterscheidenden Bytes des korrigierten Modulobjektcodes (22) ermittelt werden,

    – die im vorangehenden Schritt ermittelte Position und der Wert sowie der Name des Moduls als ein Eintrag (34) zu der Korrekturanweisung (33) hinzugefügt werden,

    – optional bei aufeinanderfolgenden Abweichungen nur die erste Position und eine Folge von Werten sowie der Name des Moduls als ein Eintrag (34) zu der Korrekturanweisung (33) hinzugefügt werden,

    – ermittelt wird, ob eine Folge von geänderten Bytes eine Adresse innerhalb des Objektcodes eines weiteren Moduls (23) angibt, und der Name des anderen Moduls sowie die Adresse der Korrekturanweisung (33) hinzugefügt werden.
  6. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Korrekturanweisung (33) während der Bearbeitung des modifizierten Modulquelltextes (13) vom Compiler (40) erstellt wird, indem

    – für jeden Objektcodeabschnitt, der einem wegfallenden oder hinzukommenden Abschnitt im modifizierten Modulquelltext (13) entspricht, die Position relativ zum Beginn des ursprünglichen Modulobjektcodes (20) und der Wert jedes Bytes des Objektcodeabschnitts ermittelt wird,

    – die im vorangehenden Schritt ermittelte Position und der Wert sowie der Name des Moduls als ein Eintrag (34) zu der Korrekturanweisung (33) hinzugefügt werden,

    – optional bei aufeinanderfolgenden Abweichungen nur die erste Position und eine Folge von Werten sowie der Name des Moduls als ein Eintrag (34) zu der Korrekturanweisung (33) hinzugefügt werden,

    – ermittelt wird, ob eine Folge von geänderten Bytes eine Adresse innerhalb des Objektcodes eines weiteren Moduls (23) angibt, und der Name des anderen Moduls sowie die Adresse der Korrekturanweisung (33) hinzugefügt werden.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass beim Erstellen der Korrekturanweisung (33) eventuell getroffene Maßnahmen des Compilers (40) zur Optimierung des ursprünglichen (20) oder korrigierten (22) Modulobjektcodes berücksichtigt werden, insbesondere falls der Compiler (40) ein Hochsprachencompiler oder ein Cross-Assembler ist.
Es folgen 5 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com