Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
explizite Änderung der Software möglich. Alternativ können zusätzliche Informationen von außen
hinzugefügt werden, die das Auffinden der Verweise ermöglichen.
4.4.2.1 Statische Verweise
Wie bereits erwähnt, werden statische Verweise durch Einträge in der Relokationstabelle beschrieben.
Anhand dieser Informationen kann festgestellt werden, ob ein Verweis auf ein Modul existiert. Falls
ein Verweis existiert, so ist die genaue Position in den Relokationsdaten beschrieben. Eine Anpassung
des Verweises kann somit leicht vorgenommen werden.
4.4.2.2 Dynamische Verweise durch indirekte Nutzung
Wird ein Modul, also eine Variable oder eine Funktion, indirekt genutzt, so bedeutet das, dass an der
Stelle der Nutzung nicht direkt die Adresse des Elements durch den Linker eingefügt wird, sondern
dass die Adresse bereits zu einem früheren Zeitpunkt im Speicher abgelegt wurde und nun von dort
benutzt wird.
Ein einfaches, bereits genanntes Beispiel ist ein Funktionsaufruf mittels Funktionszeiger. Die Adresse
der Funktion wurde vorher in einer Variablen als Funktionszeiger abgelegt. Das allgemeine Problem
ist, dass man feststellen muss, wo die Adresse der Funktion überall benutzt wird, das heißt, wo überall
Kopien angelegt werden. Nur dann kann man alle Verweise auf die Funktion in Erfahrung bringen, um
sie anzupassen.
Lösungsansatz: Verweise aufspüren
Den Weg des Funktionszeigers kann man mithilfe einer Code- und Datenflussanalyse [Hec77] verfolgen.
Man beginnt an der Stelle, an der die Adresse einer Funktion erstmals verwendet wird. Bei dem
oben genannten Beispiel wird die Adresse der Funktion in einer Variablen abgelegt. Diese Position
lässt sich anhand der Relokationsinformationen bestimmen. Von dort ausgehend wird der weitere
Programmablauf simuliert, indem der vorliegende Binärcode teilweise interpretiert wird. Dabei wird die
Position der Adresse überwacht und Zugriffe verfolgt. Mithilfe dieser Technik kann man nachvollziehen,
wohin die Adresse kopiert, wie sie verwendet und wo sie abgelegt wird.
Diese Analyse hat jedoch einige Nachteile. Zum einen ist sie architekturabhängig, da Wissen über
die Wirkung jedes Maschinenbefehls benötigt wird. Dies macht die Realisierung dieses Ansatzes sehr
aufwendig. Hinzu kommt, dass auch die Analyse selbst aufwendig sein kann und zudem nicht immer
sichergestellt ist, dass sie ein brauchbares Ergebnis liefert. Wenn sich der Programmablauf abhängig
von externen Ereignissen in verschiedene Richtungen entwickeln kann, müssen alle möglichen Wege
in der Simulation berücksichtigt werden. Liefern verschiedene Wege sich widersprechende Aussagen,
so ist das Ergebnis der Analyse für unsere Zwecke unbrauchbar. Der Aufwand muss somit sorgfältig
gegenüber dem Nutzen abgewogen werden.
Für viele Einsatzzwecke kann ein vereinfachtes Verfahren jedoch ausreichen. Dabei ist das Ziel,
lediglich festzustellen, ob die Adresse einer Funktion als Zeiger Verwendung findet oder ausschließlich
in Sprungbefehlen und Funktionsaufrufen verwendet wird. Um diese Unterscheidung zu treffen, reicht
es aus, den Code an den Stellen zu prüfen, an denen laut Relokationsinformationen eine Referenz
auf den Code eingefügt werden soll. Handelt es sich um einen Sprungbefehl, so wird die Adresse
direkt verwendet. Handelt es sich nicht um einen Sprungbefehl oder wird die Adresse im Datenbereich
eingefügt, dann wird sie vermutlich indirekt verwendet.
66