14.01.2015 Aufrufe

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

Dynamische Adaption in heterogenen verteilten eingebetteten ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

4.4 Verweise auf Module<br />

Bei manchen Architekturen kann sogar auf die Untersuchung des Codes verzichtet werden, da bereits<br />

die Art der Verknüpfung <strong>in</strong> den Relokations<strong>in</strong>formationen klarstellt, ob die Adresse <strong>in</strong> e<strong>in</strong>em Sprungbefehl<br />

verwendet wird. E<strong>in</strong> Beispiel hierfür wurde <strong>in</strong> Abbildung 4.3 bereits angedeutet: Relokationen bei<br />

AVR-Prozessoren können den Verknüpfungstyp R_AVR_CALL haben. Dies ist e<strong>in</strong> sicheres Zeichen,<br />

dass die Adresse bei e<strong>in</strong>em Sprungbefehl e<strong>in</strong>gesetzt wird.<br />

Stellt man nach Anwendung dieses vere<strong>in</strong>fachten Verfahrens fest, dass die Adresse ausschließlich <strong>in</strong><br />

Sprungbefehlen verwendet wird, so können ke<strong>in</strong>e Verweise dynamisch entstehen und die Relokations<strong>in</strong>formationen<br />

reichen aus, um alle Verweise zu identifizieren. Bei e<strong>in</strong>em negativen Ergebnis h<strong>in</strong>gegen<br />

kann die eigentliche Operation, das Löschen oder Austauchen e<strong>in</strong>es Moduls, nicht ohne zusätzliches<br />

Wissen durchgeführt werden.<br />

Für die von uns angestrebte Aufgabe, dem dynamischen Anpassen e<strong>in</strong>er Laufzeitumgebung, reicht<br />

dieser Ansatz aus, da die Software bekannt ist. Will man das vere<strong>in</strong>fachte Verfahren auch bei unbekannter<br />

Software e<strong>in</strong>setzen, so muss man die Verwendung von Funktionszeigern für Funktionen,<br />

die ausgetauscht oder entfernt werden sollen, verbieten oder auf bekannte Situationen e<strong>in</strong>schränken.<br />

Auch wenn diese Forderung zunächst als e<strong>in</strong>e starke E<strong>in</strong>schränkung ersche<strong>in</strong>t, so ist es nicht unüblich,<br />

auf den E<strong>in</strong>satz von Zeigern zu verzichten. Sie stellen e<strong>in</strong>e Fehlerquelle besonders für unerfahrene<br />

Programmierer dar. Bei der Softwareentwicklung für e<strong>in</strong>gebettete Systeme wird daher der E<strong>in</strong>satz von<br />

Zeigern häufig e<strong>in</strong>geschränkt oder verboten. E<strong>in</strong> bekanntes Beispiel hierfür stellt Misra-C [MIS98]<br />

dar. Dabei handelt es sich um Richtl<strong>in</strong>ien für den Gebrauch der Programmiersprache C <strong>in</strong> sicherheitskritischen<br />

Systemen im Bereich der Automobil<strong>in</strong>dustrie, welche später für allgeme<strong>in</strong>e e<strong>in</strong>gebettete<br />

Systeme überarbeitet wurden [MIS04]. Die Misra-Regeln verbieten bestimmte Konstrukte <strong>in</strong> C, welche<br />

die Intension des Autors nicht e<strong>in</strong>deutig erkennen lassen und daher fehleranfällig s<strong>in</strong>d. Unter anderem<br />

wird auch der E<strong>in</strong>satz von Funktionszeigern e<strong>in</strong>geschränkt.<br />

Zeiger auf Funktionen, die automatisch erzeugt werden, s<strong>in</strong>d h<strong>in</strong>gegen gut handhabbar, wenn man<br />

das Vorgehen des Generators kennt. In C++ beispielsweise werden implizit Funktionszeiger im Rahmen<br />

von virtuellen Methodenaufrufen verwendet. Die Methodentabelle wird dabei vom Compiler erzeugt.<br />

Ihr Aufbau ist bekannt, daher kann sie auf entsprechende Zeiger h<strong>in</strong> überprüft werden.<br />

Lösungsansatz: Position erhalten<br />

Beim Austauschen von Funktionen gibt es noch e<strong>in</strong>e andere Möglichkeit, mit <strong>in</strong>direkten Verweisen<br />

umzugehen. Anstatt alle Verweise aufzuspüren und abzuändern, kann man dafür sorgen, dass die<br />

Funktion weiterh<strong>in</strong> an der ursprünglichen Position erreichbar bleibt. Existierende Verweise bleiben<br />

dadurch gültig und das Anpassen der Verweise kann entfallen.<br />

Für diese Optimierung müssen die E<strong>in</strong>sprungpunkte des neuen Moduls an genau denselben Adressen<br />

abgelegt werden können wie die E<strong>in</strong>sprungpunkte des alten Moduls. Das bedeutet, dass die Schnittstellen<br />

des Moduls an denselben relativen Positionen <strong>in</strong>nerhalb des Moduls se<strong>in</strong> müssen und, dass<br />

genügend Platz auf dem Zielgerät vorhanden se<strong>in</strong> muss, um das neue Modul an der alten Position<br />

abzulegen.<br />

Im Idealfall lässt sich die Überprüfung reduzieren auf die Prüfung des vorhandenen Speicherplatzes.<br />

Module repräsentieren, wenn möglich, genau e<strong>in</strong>e Funktion oder e<strong>in</strong>e Variable. Die Schnittstelle<br />

solcher Module liegt dann immer am Anfang des Moduls und erfüllt somit die Voraussetzungen für den<br />

e<strong>in</strong>fachen Austausch. Man muss somit nur noch sicherstellen, dass das neue Modul kle<strong>in</strong>er oder gleich<br />

groß ist wie das alte Modul oder dass im Programmspeicher des Zielgeräts h<strong>in</strong>ter dem alten Modul<br />

genügend freier Speicher vorhanden se<strong>in</strong>, um die Größendifferenz zum neuen Modul aufzunehmen.<br />

Kennt man alle möglichen Varianten e<strong>in</strong>er Funktion, so kann man, ähnlich zum Vorgehen bei der<br />

Überlagerungstechnik (siehe Abschnitt 2.1.3), den maximal benötigten Platz anhand der größten Funk-<br />

67

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!