DE69232761T2

DE69232761T2 - Verfahren und vorrichtung zur aenderung von dynamische zuweisbaren objektcodedateien

Info

Publication number: DE69232761T2
Application number: DE69232761T
Authority: DE
Inventors: Reed Hastings
Original assignee: Rational Software Corp
Current assignee: International Business Machines Corp
Priority date: 1991-06-21
Filing date: 1992-06-05
Publication date: 2003-04-24
Anticipated expiration: 2012-06-06
Also published as: EP0591360A4; EP0591360B1; CA2111958A1; US5535329A; US6206584B1; DE69232761D1; EP0591360A1; AU2188792A; US5835701A; US5335344A; US6618824B1; CA2111958C; WO1993000633A1; US20040107217A1; US5193180A; US7210118B2

Description

Die vorliegende Erfindung betrifft allgemein ein Verfahren und eine Vorrichtung zum Modifizieren von Relativobjektdateien. Die vorliegende Erfindung betrifft insbesondere ein Verfahren zum Einfügen zusätzlicher Anweisungen und Daten in eine existierende Relativobjektdatei eines Computerprogramms für einen beliebigen Zweck. Dieser Zweck ist insbesondere die Überwachung von Speicherzugriff durch das Computerprogramm.
Trotz der Zunahme der Geschwindigkeiten von Zentraleinheiten und der Softwarekomplexität in der letzten Zeit verlassen sich die meisten Programmierer weiterhin auf Entwicklungstools, die vor mehr als fünfzig Jahren entwickelt wurden und die sich seitdem nicht bedeutend geändert haben. Diese Entwicklungstools haben ernsthafte Unzulänglichkeiten, die die Schwierigkeiten des Entwickelns großer, komplexer Programme noch verschärfen.
Probleme mit der Entwicklung von Applikationen in C/C++ sind häufig ernsthafter als mit anderen Programmiersprachen, sind aber recht typisch. Zeiger- und Speichermanagement- Einrichtungen von C/C++ machen es schwer, große und robuste Programme zu erstellen. Vorsichtige C/C++ Programmierer wenden derzeit viele kommerzielle Objektcode-Bibliotheken nur zögerlich an, weil sie besorgt sind, dass sie später möglicherweise Wochen an Zeit bei der Suche nach Wild-Pointer- Bugs verlieren, die durch die Verwendung einer bestimmten Bibliothek verursacht wurden. Die Schwierigkeit beim Ermitteln dieser Arten von Programmierbugs und vielen anderen ist unmittelbar mit der Art und Weise, in der ablauffähiger Code von Source-Code erzeugt wird, sowie mit den Unzulänglichkeiten derzeitiger Entwicklungstools verbunden.
Der Vorgang des Transformierens von Source-Code in "ablauffähigen" Code ist, kurz ausgedrückt, wie folgt. Der Source-Code für ein typisches Computerprogramm wird in viele Dateien unterteilt. Einige dieser Dateien können High-Level- Sprachcode wie C, C++, Pascal, Fortran, Ada oder PL1, andere können Assemblersprachcode enthalten. Jede High-Level- Sprachdatei wird von einem sprachspezifischen Compiler entweder in eine Relativobjektdatei oder in eine Assemblersprachdatei umgesetzt. Ein Assembler setzt die Assemblersprachdateien in Relativobjektdateien um. Ein Programmbinder (Linker) führt alle Relativobjektdateien zu einem einzelnen ablauffähigen Programm zusammen.
Wenn Programme größer und komplexer werden, wird es immer schwieriger, sie zu testen und ihre Fehler zu finden. Wenn Aspekte des Verhaltens eines Programms überwacht oder analysiert werden sollen, besteht die derzeitige Praxis darin, den Compiler zu veranlassen, die zusätzlichen Anweisungen auszugeben, die zum Ausführen der gewünschten Überwachung benötigt werden. Ein Beispiel hierfür existiert in vielen Pascal-Compilern; eine Art und Weise besteht typischerweise darin, den Compiler anzuweisen, die zusätzlichen Anweisungen auszugeben, die zum Prüfen von Array-Grenzen zur Laufzeit benötigt werden, und einen Fehler zu signalisieren, wenn eine Verletzung vorliegt. Ein weiteres Beispiel existiert in vielen Unix/C-Compilern; die meisten Compiler geben auf Anforderung zusätzliche Anweisungen aus, um aufzuzeichnen, wie oft jede Funktion aufgerufen wurde.
Ein weiteres Beispiel für diese derzeitige Praxis ist in dem Artikel von Fun Ting Chan et al. "AIDA - A Dynamic Data Flow Anomaly Detection System for Pascal Programs" beschrieben (Herausgeber Software Practice & Experience, Bd. 17, Nr. 3, März 1987, Chichester, GB, Seiten 227 bis 239). Dieser Artikel beschreibt ein automatisiertes Instrumentationssystem zum Durchführen von Datenablaufanalysen für Pascal-Programme. Die Software führt eine Programminstrumentierung durch Einfügen von Software-Probes in ein Ursprungsprogramm durch. Das instrumentierte Ursprungsprogramm wird dann kompiliert und die Datenablaufanalyse während der Ausführung des Programms durchgeführt.
Der Ansatz, den Compiler zu veranlassen, die zusätzlichen Anweisungen auszugeben, die zum Ausführen eines Überwachungs- oder Analyseschemas benötigt werden, hat jedoch wenigstens drei erhebliche Mängel: Erstens ist das Modifizieren des Compilers zum Ausgeben neuer Sequenzen schwierig und in der Praxis nahezu unmöglich, weil die meisten Programmierer den Source-Code zum Compiler nicht haben. Zweitens kann das Neukompilieren aller Programmdateien, nur um die zusätzlichen eingefügten Anweisungen zu erhalten, sehr zeitaufwändig und verschwenderisch sein; und schließlich geht nicht sämtlicher Code durch einen Compiler; ein Teil des Codes wird in Assemblersprache geschrieben und erhält die darin eingefügten neuen Anweisungen nicht. Somit kann nicht einfach jegliche Überwachung, die vollständig sein muss, damit sie ihren Zweck richtig erfüllt, nur durch den Compiler implementiert werden.
Einige der schlimmsten Entwicklungsprobleme betreffen die Schwierigkeit beim Suchen und Eliminieren einer großen Klasse von Fehlern in Bezug auf Speicherzugriffe. Zu den wichtigsten speicherzugriffsbezogenen Fehlern, die ein Programmierer erkennen muss, gehören Array-Grenzverletzungen, uninitialisierte Speicherlesevorgänge, Zugriffe auf freien Speicher und sich seltsamerweise verändernde Daten.
Array-Grenzverletzungen (wobei eine Array eine Ansammlung von im Speicher nebeneinander liegenden Daten ist) treten bei Gelegenheiten auf, wenn ein Programm hinter dem Ende oder vor dem Anfang einer Array liest oder schreibt und auf jedes Datenelement zugreift, das sich zufällig an dieser Speicherstelle befindet.
Zu uninitialisierten Speicherlesevorgängen kommt es dann, wenn ein Programm Speicherkapazität für die Datenspeicherung zuweist, aber diese Kapazität nicht vollständig initialisiert. Später wird dann ein uninitialisierter Teil gelesen und ungewollt ein Zufallswert gegeben, der zuweilen zu einem Ausfall des Programms führen kann, manchmal aber auch nicht.
Zugriffe auf freien Speicher bedeuten eine Situation, bei der ein Programm die Zuordnung von Speicherkapazität aufhebt, sie aber fälschlicherweise weiter benutzt. Wenn das Programm diesen Speicherplatz dann für einen anderen Zweck erneut zuweist, wird derselbe Speicherplatz für zwei verschiedene Zwecke verwendet, und das Programm wird möglicherweise falsch arbeiten.
Der Ausdruck "sich seltsamerweise verändernde Daten" ist ein Versuch, alle anderen Fälle zusammenzufassen. Es gibt häufig viele verschiedene Möglichkeiten, ein Datenelement zu ändern, insbesondere ein "globales" Datenelement. Es kann für den Programmierer sehr schwer sein zu entdecken, welche Funktion bei einem Ablauf des Programms das Datenelement fälschlicherweise verändert. Was der Programmierer braucht, ist ein Überwachungsprogramm, das ihm jede Veränderung eines bestimmten Datenelementes anzeigt (dies wird als "Watchpoint" bezeichnet).
Der Programmentwickler braucht eindeutig eine umfassende Art und Weise, den Ablauf heutiger und zukünftiger Programme, insbesondere deren Speicherzugriff, zu überwachen.
Die Erfindung stellt ein Verfahren zum Signalisieren von Fehlern im Speicherzugriff sowie ein zugehöriges Computersystem, ein Computerprogramm und ein Computerspeichermedium gemäß Definition in den beiliegenden unabhängigen Ansprüchen bereit, auf die nunmehr Bezug zu nehmen ist. Bevorzugte oder vorteilhafte Merkmale der Erfindung sind in den abhängigen Unteransprüchen dargelegt.
Somit stellt die Erfindung in einem ersten Aspekt vorteilhafterweise ein Verfahren bereit, bei dem eine Objektcodedatei durch Einfügen zusätzlicher Anweisungen und/oder Daten zwischen vorexistierenden Anweisungen und Daten expandiert wird, die ebenfalls auf irgendeine Weise modifiziert werden können. Es kann eine grundsätzlich unbegrenzte Vielzahl zusätzlicher Anweisungen und Daten für eine ebenso breite Palette verschiedener Zwecke eingefügt werden. Nach dem Einfügungsschritt werden die Offsets in der Datei geprüft und ggf. modifiziert, so dass sie die neuen Positionen der vorexistierenden Anweisungen und Daten reflektieren, so dass der expandierte Code ordnungsgemäß abläuft. In der bevorzugten Ausgestaltung werden zusätzliche Offsets in Symboltabellen, Datenverschiebungstabellen und Anweisungsverschiebungstabellen auf dieselbe allgemeine Weise aktualisiert wie die anderen Offsets. Das Grundverfahren in der Ausgestaltung lautet wie folgt:
Im Speicherraum wird eine alte Objektcodetabelle angelegt, die die vorexistierenden Anweisungen und Daten enthält. Es wird auch Raum für andere Tabellen zugewiesen: eine neue Objektcodetabelle, eine Zwischenelement-Offsettabelle, eine Vorwärtsindextabelle und eine Vorwärtssteuerindextabelle. Für jedes Element in der alten Objektcodetabelle (ob Anweisung oder Datenelement) werden die folgenden vier Schritte durchgeführt: (1) Erstellen eines neuen Codeblocks, der gewünschte zusätzliche Anweisungen und/oder Daten und das Element umfasst, und Speichern desselben in der neuen Objektcodetabelle; (2) Speichern der Stelle des Elementes innerhalb der neuen Objektcodetabelle in der Vorwärtsindextabelle; (3) Speichern der Stelle des neuen Codeblocks innerhalb der neuen Objektcodetabelle in der Vorwärtssteuerindextabelle; und (4) für Elemente, die Zwischenelement-Offsets enthalten, Speichern der Stelle innerhalb der alten Objektcodetabelle des Offsets und der Basis, von der aus er gemessen wird, in der Zwischenelement-Offsettabelle. Danach wird für jedes Paar von Offset/Basisstellen in der Zwischenelement-Offsettabelle der in der neuen Objektcodetabelle gespeicherte Offset anhand der Indextabellen aktualisiert. Schließlich werden die Offsets in beliebigen Symboltabellen, Anweisungsverschiebungsstrukturen oder Datenverschiebungsstrukturen in der alten Objektcodedatei so aktualisiert, dass der neue Offset auf die Speicherstelle in der neuen Objektcodetabelle auf die Stelle verweist, zu der das verwiesene Element bewegt wurde.
In einem zweiten Aspekt kann die Erfindung vorteilhafterweise ein Verfahren bereitstellen, bei dem alle oder im Wesentlichen alle Speicherzugriffe eines bestimmten Programms zwecks Durchführung einer Fehlerprüfung überwacht werden (nicht einschließlich der Speicherzugriffe für Anweisungsabrufe). In einer Ausgestaltung werden alle Objektcodedateien für ein ablauffähiges Programm verarbeitet und die Anweisungen hinzugefügt, um das folgende Überwachungsschema zu implementieren. Eine Speicherstatusarray wird mit einem Eingang für die meisten Speicherstellen erstellt, auf die das Programm gültigerweise zugreift. Jeder Eintrag gibt den Zustand der entsprechenden Speicherstelle an, und es können drei Zustände vorliegen: unzugewiesen und uninitialisiert, zugewiesen aber uninitialisiert, sowie zugewiesen und initialisiert. Vor jeder vorexistierenden Anweisung, die auf Speicherstellen zugreift oder die den Speicherstatus ändern kann, werden zusätzliche Anweisungen hinzugefügt, um die Speicherstatusarray aufrecht zu erhalten und die Speicherstatusarray zum Überprüfen auf Fehler in Bezug auf das Schreiben von unzugewiesenem Speicher und auf Lesen von unzugewiesenem oder uninitialisiertem Speicher zu verwenden. In einer besonderen Ausgestaltung werden die Datensektionen der Objektcodedateien mit zusätzlichen Dummy-Einträgen zwischen jedem Datenelement expandiert. Diesen zusätzlichen Einträgen wird der Status unzugewiesen und uninitialisiert zugeordnet, und sie unterstützen bei der Erkennung von Array- Grenzverletzungen und ähnlichen Datenfehlern. In einer weiteren besonderen Ausgestaltung wird eine Liste von Speicher- oder Datenelementstellen gespeichert, die Überwachungsstellen (Watchpoints) sind, mit denen eine umfassendere Überwachung durchgeführt werden soll.
Ein weitergehendes Verständnis des Wesens und der Vorteile der Erfindung kann unter Bezugnahme auf die übrigen Teile der Beschreibung sowie auf die Zeichnungen gewonnen werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockdiagramm einer Relativobjektdatei, die durch eine Ausgestaltung der Erfindung zu einer neuen Relativobjektdatei expandiert wird;
Fig. 2 ist ein Blockdiagramm, das die Beziehung zwischen einer Relativobjektdatei und einer alten Objektcodetabelle zeigt;
Fig. 3 illustriert das allgemeine Daten/Anweisungs- Einfügungsverfahren;
Fig. 4 ist ein Ablaufdiagramm des allgemeinen Daten/Anweisungs-Einfügungsverfahrens;
Fig. 5 illustriert den allgemeinen Ablauf zum Implementieren eines Überwachungsschemas durch Modifizieren der Objektdateien für ein ablauffähiges Programm;
Fig. 6 illustriert die verschiedenen Speicherzugriffszustände, die in einer bestimmten Ausgestaltung der Erfindung verwendet werden, die Speicherzugriffe eines Programms verfolgen soll;
Fig. 7 ist eine virtuelle Speicherabbildung, die die Abschnitte von virtuellem Speicherplatz zeigt, der einem Pragramm zur Verfügung steht;
Fig. 8 illustriert, wie Aufrufe an Betriebssystemroutinen gemäß einer Ausgestaltung der Erfindung gehandhabt werden, die Speicherzugriffe überwachen soll;
Fig. 9 illustriert, wie die Objektdateien für ein ablauffähiges Programm durch eine Ausgestaltung der Erfindung verarbeitet werden, die Speicherzugriffe überwachen soll; und
Fig. 10 illustriert die Bildung neuer Codeblöcke zum Implementieren der Speicherzugriffsüberwachung der bevorzugten Ausgestaltung.

BESCHREIBUNG DER BEVORZUGTEN AUSGESTALTUNG

Willkürliche Anweisungseinfügung

Ein Aspekt der vorliegenden Erfindung ist ein Verfahren zum Expandieren einer Relativobjektdatei, typischerweise durch Einfügen neuer Anweisungen und Daten zwischen vorexistierenden Anweisungen und Daten der Datei, ohne dass eine Neukompilation notwendig wäre. Fig. 1 illustriert eine vorexistierende Objektcodedatei 1 ("oldfile.o"), die durch ein Expansionsmittel 5 zur Bildung einer neuen Objektcodedatei 1 ("newfile.o") erweitert wird. In der bevorzugten Ausgestaltung ist das Expansionsmittel 5 ein Universalcomputer mit einem Speicher, der von einem Computerprogramm gesteuert arbeitet. Da das Expansionsmittel 5 Objektdateien als Eingang erhält, können Überwachungsschemata umfassend sein; das Verfahren kann auf sämtlichen Code angewendet werden, der in das endgültige ablauffähige Produkt eingeht, und nicht nur auf diejenigen Abschnitte, für die Source-Code zur Verfügung steht.
Die nachfolgend beschriebene besondere Ausgestaltung des Expansionsmittels 5 ist für ein auf Sun OS 4.1.1 laufendes Sun3/60 unter Verwendung der C/C++ Compiler von Sun Microsystems, Inc. aus Mountain View in Kalifornien ausgelegt, so dass die Beschreibung in einigen Hinsichten für dieses System spezifisch ist. In diesem System hat ein Standardformat für eine Relativobjektdatei 1 (.o Datei) 7 Teile, wie in Fig. 2 gezeigt ist:
- Ein 32-Byte-Header II, der die Längen der übrigen Teile beschreibt;
- Binäre Maschinenanweisungen 12a;
- Binäre Daten 12b;
- Symbole 13, die einen Namen (einen Index auf die Stringsektion), einen Typ, einen Wert und andere weniger wichtige Felder haben;
- Anweisungsverschiebungsdatenstrukturen 14, die vorgeben, welche Bytes in der Anweisungssektion ungelöste Referenzen auf andere Daten oder Funktionen sind;
- Datenverschiebungsdatenstrukturen 15, die vorgeben, welche Bytes in der Datensektion ungelöste Referenzen auf andere Daten oder Funktionen sind;
- Strings 16, die Namen der Symbole.
Die vorexistierenden Anweisungen enthalten allgemein viele Referenzen auf andere Anweisungen im Sinne von Offsets, d. h. im Sinne der Anzahl von Bytes, die die Anweisungen in der Objektcodedatei trennen. Wenn neue Anweisungen in den Code eingefügt werden, werden diese Offsets durch das Expansionsmittel 5 korrigiert. Eine einfache Modifizierung von Anweisungen, im Gegensatz zum Hinzufügen von neuen, kann die Anweisung verlängern oder verkürzen und auch eine Korrektur von Offsets erfordern. Ferner enthalten die Anweisungen, Symbole und Verschiebungsstrukturen auch Referenzen zu Daten und Anweisungen, und diese Referenzen haben häufig die Form eines Offsets vom Anfang der Objektdateisektion, die die Daten und Anweisungen enthält. Diese werden auf ähnliche Weise aktualisiert.
Das Wertefeld bestimmter Symbole ist ein Offset zu den vorexistierenden Anweisungen und Daten und muss daher durch den Offeet der Speicherstelle ersetzt werden, zu der das vorexistierende Element weitergeleitet wurde. Die Symbole, die aktualisiert werden müssen, sind diejenigen, deren Typ-Feld eines der folgenden ist: N_TEXT, N_BSS, N_DATA, N_STSSYM, N_LCSYM, N_SO, N_SOL, N_ENTRY, N_LBRAC, N_RBRAC und N_ECOMM. Diese Symboltypen sind in der von Sun gelieferten include-Datei /usr/include/stab.h definiert (in der "Text" sich allgemein auf Anweisungen bezieht). Verschiebungsstrukturen haben ein Feld mit der Bezeichnung "r_address", das (wie das Wertefeld von Symbolen) ein Offset zu den vorexistierenden Anweisungen und Daten ist und mit der neuen Stelle aktualisiert werden muss, zu der die Bytes, auf die ursprünglich gezeigt wurde, bewegt wurden. Darüber hinaus sind für örtliche Verschiebungen die Bytes, auf die das Feld "r_address" zeigt, an sich ein Offset, der aktualisiert werden muss.
Die eingefügten zusätzlichen Anweisungen sind häufig mit bestimmten vorexistierenden Anweisungen assoziiert und müssen jedes Mal dann ausgeführt werden, wenn diese vorexistierende Anweisung ausgeführt wird, in einigen Fällen unmittelbar vor der Ausführung dieser vorexistierenden Anweisung. Einige der Referenzen auf Anweisungen in der vorexistierenden Objektcodedatei 1 werden Offsets sein, die zum Übertragen der Programmsteuerung auf diese Punkte während der Ausführung verwendet werden. In diesem Fall werden die Anweisungsoffsets so eingestellt, dass sie auf den Anfang des zusätzlichen Codes in Verbindung mit dieser vorexistierenden Anweisung zeigen. In anderen Fällen, z. B. dann, wenn eine Referenz auf Daten zeigt, selbst dann, wenn zusätzliche Daten um ein bestimmtes Datenelement herum eingefügt werden, muss die Referenz möglicherweise trotzdem direkt auf dieses Datenelement zeigen. Die Daten und Anweisungen werden allgemein als eine Sektion behandelt. Referenzen auf Daten und Anweisungen werden vom Anfang der Sektion indexiert, die die Anweisungen und Daten enthält. Daten können auch mit Anweisungen vermischt sein. Das Expansionsmittel 5 ermittelt, ob ein bestimmter Wert in der Objektdatei ein Datenelement oder eine Anweisung ist, und ermittelt auch den Zweck jedes Referenzoffsets. Ferner setzen Compiler häufig unbenannte Daten, wie z. B. Konstanten, auf die im Source-Code verwiesen wird, in die Anweisungssektion, aber nicht innerhalb einer Funktion. Um diese Daten von tatsächlichen Anweisungen zu unterscheiden, wird eine vereinfachte Totcode-Analyse verwendet, die bei den benannten Eintragspunkten beginnt, die von den Symbolen des Typs N_TEXT vorgegeben werden, und den Eintragspunkten, die von den Anweisungsverschiebungsstrukturen abgeleitet werden. Anweisungen, die nicht erreicht werden können, werden als Daten angesehen. Eine Ausnahme ist die, dass einige Objektcode- Bibliotheken von wenigstens einem früheren Sun-Betriebssystem, 4.03, mehrere benannte Eintrittspunkte des Typs N_TEXT haben, die Daten und keine Eintrittspunkte sind und die daher für diese Zwecke ignoriert werden. Die Bezeichnungen dieser Daten sind "_BYADDR", "_NETGROUP", "_ypsleeptime" und "_ypserv_timeout". Eine weitere Ausnahme ist die, dass wenigstens ein Compiler, gcc (von der Free Software Foundation) benannte Konstantendaten in die Anweisungssektion setzt. Wenn die Objektdatei von gcc kompiliert wurde, wird das erste Wort jedes benannten Eintrittspunktes geprüft. Wenn es sich um eine Bindeanweisung (Link) handelt, wird der Eintrittspunkt als Funktion, ansonsten als Daten angesehen.
Nachfolgend wird der Anweisungseinfügungsprozess des Expansionsmittels 5 mit Bezug auf Fig. 2-4 ausführlich beschrieben. Fig. 2 zeigt ein Layout des Speichermediums einer Relativobjektdatei 1, die eine Sektion 12 von Anweisungen 12a und Daten 12b enthält. Sektion 12 wird in einen Speicherblock kopiert, der für die alte Objektcodetabelle 20 zugewiesen wurde (siehe FILES.C, "Initialize"). Jedes Element in Tabelle 20 wird allgemein durch eine horizontale Linie angedeutet, und die Byte-Stelle für jedes Element ist auf der linken Seite zu sehen (Hinweis: Byte-Stellen sind dezimal dargestellt); unterschiedliche Elemente haben unterschiedliche Längen. Das Expansionsmittel 5 weist Speicherkapazität für andere Tabellen zu (siehe Fig. 3): eine neue Objektcodetabelle 30, eine Vorwärtsindextabelle 40, eine Vorwärtssteuerindextabelle 50 und eine Zwischenelement-Offsettabelle 60, die nachfolgend beschrieben werden. Danach wird, beginnend am Anfang der alten Objektcodetabelle 20, jeder Eintrag in der Tabelle 20 verarbeitet.
Fig. 4 zeigt eine allgemeine Ablauftabelle für das mit dem Expansionsmittel 5 durchgeführte Verfahren. Block 100 gibt die Vorbereitung der Tabellen 20, 30, 40, 50 und 60 (oben beschrieben) an, Block 110 zeigt den Schritt des Identifizierens von Eintrittspunkten zu Funktionen an (siehe INSERT.C, "FindFunctions"). Block 115 zeigt die Expansion aller Funktionen an; die Details des an jeder Funktion durchgeführten Expansionsprozesses sind in der aus den Blöcken 120-190 bestehenden Schleife ersichtlich (siehe INSERT.C, "DoOneFunction").
In Schritt 120 von Fig. 4 wird das erste Element in der alten Objektcodetabelle gewählt. Fig. 3 zeigt Teile von Speicherplatz, der bei den Schritten 130 bis 200 des Expansionsprozesses betroffen ist. Speicherstellen (Bytes) 1 bis 125 von Tabelle 20 wurden bereits verarbeitet und belegen jetzt Speicherstellen 1 bis 181 der neuen Objektcodetabelle 30. Der nächste Eintrag (eine Objektcodeanweisung in einer Funktion, durch das Kurzzeichen "BEQ +6" angedeutet) an der Stelle 126 in der alten Objektcodetabelle 20 wird dann in Schritt 130 verarbeitet. Dies ist eine Vier-Byte-Anweisung; sie beginnt bei Stelle 126, die nächste Anweisung beginnt bei Stelle 126 + 4 = 130 (dezimal). Zwei Opcode-Bytes werden einfach als BEQ angedeutet, und die "6" ist ein Zwei-Byte- Offset, der auf die bei Stelle 132 beginnende "RTS"-Anweisung zeigt. Das Expansionsmittel 5 bildet einen neuen Codeblock 33 (siehe INSERT.C, "DoOnelnstruction"), der lediglich das BEQ- Statement enthält, da keine zusätzlichen Anweisungen oder Daten eingefügt werden. Der Offset wird durch ein Fragezeichen in der Tabelle 30 angedeutet, weil sein neuer Wert noch nicht bekannt ist. Das Expansionsmittel 5 weist maximal vier Bytes für den Offset zu, obwohl der ursprüngliche Offset nur zwei Bytes war (und der BEQ-Opcode wird geringfügig modifiziert, so dass er einem Vier-Byte-Offset entspricht). Dies erfolgt nach der Expansion, der neue Offset könnte für die Zahl der Bytes des vorherigen Offsets möglicherweise zu groß sein.
Nunmehr gemeinsam bezugnehmend auf die Fig. 3 und 4, in Schritt 140 wird die Stelle der BEQ-Anweisung in der neuen Objektcodetabelle 30 (Stelle = 182) in der Stelle 126 einer Vorwärtsindextabelle 40 gespeichert. Im Allgemeinen wird die neue Stelle jedes Bytes einer Anweisung in Tabelle 40 gespeichert, aber in diesem Fall befinden sich die einzigen signifikanten Einträge an Stelle 126 von Tabelle 40, was bedeutet, dass das BEQ-Statement jetzt an Stelle 182 von Tabelle 30 und an Stelle 128 von Tabelle 40 beginnt, was bedeutet, dass der Offset des BEQ-Statements jetzt an Stelle 184 von Tabelle 30 beginnt. Die Ellipsen ("...") bedeuten, dass ein oder mehrere Werte vorliegen, aber keine Signifikanz haben. So würde beispielsweise Stelle 129 von Tabelle 40 dem zweiten Byte des BEQ-Offset an Stelle 129 zu Tabelle 20 entsprechen; der Offset wird jedoch von zwei auf vier Bytes expandiert, so dass die individuellen Bytes des Offsets nicht separat indexiert werden können.
Als Nächstes wird in Schritt 150 die Stelle des neuen Codeblocks 33 (Stelle = 182) in der Vorwärtsindexsteuertabelle 50 gespeichert. Es gibt zwar für die neuen Stellen für jedes Byte des BEQ 6 Statements Platz, aber es ist nur die Stelle des Anfangs des Statements signifikant. Man beachte, dass sich in einigen Expansionsschemata die vorexistierende Anweisung möglicherweise immer am Anfang des neuen Codeblocks befindet, und in diesem Fall würde dieselbe Information in der Vorwärtsindextabelle 40 und in der Vorwärtssteuerindextabelle 50 aufgezeichnet; eine doppelte Aufzeichnung dieser Information würde jedoch eine Platzverschwendung bedeuten. Der beste Ansatz sieht daher eine Vorwärtstabelle vor, die, wie oben erläutert, die beiden separaten Untertabellen, die Vorwärtsindextabelle 40 und die Vorwärtssteuerindextabelle 50 beinhalten kann oder auch nicht.
Als Nächstes bestimmt in Schritt 160 das Expansionsmittel 5, dass diese Anweisung einen Zwischenelement-Offset enthält (ein Zwischenelement-Offset ist eine Referenz auf eine Anweisung oder ein Datenelement, die/das als Distanz in Bytes von einer zweiten Anweisung oder einem zweiten Datenelement ausgedrückt wird). Diese Bestimmung erfolgt durch Untersuchen des Opcodes der Anweisung (siehe INSERT.C, "RecordPcRelInstr"). Da diese Anweisung einen Zwischenelement-Offset enthält, wird Schritt 170 durchgeführt, so dass die alte Stelle des Offsets (128 in Tabelle 20), die alte Stelle der Basis, von der der Offset gemessen wurde (126 in Tabelle 20), und die alte Größe des Offsets (2 Bytes) alle in der Zwischenelement-Offsettabelle 60 gespeichert werden. Für eine beliebige Anweisung, die den Beginn einer Switch-Tabelle von Zwischenelement-Offsets denotiert, wird jeder Offset in Tabelle 60 wie oben gespeichert, wobei der Anfang der Switch-Tabelle als Basis eingegeben wird (siehe INSERT.C, "DoSwitchTable"). In Schritt 180 wird die Schleife wiederholt, wenn noch unverarbeitete Elemente vorhanden sind. Da es in Tabelle 20 noch unverarbeitete Elemente gibt, wählt Schritt 190 das nächste Element "Add 1, (A0)", und die Schleife wird wieder bei Schritt 130 begonnen.
Durch Wiederholen der Schritte 130-180 bildet das Expansionsmittel 5 einen neuen Codeblock 35 von der Add- Anweisung und neuen Anweisungen α, β, und γ, die in diesem besonderen Fall vor der Add-Anweisung stehen. Dieser neue Codeblock wird an Stelle 188 der neuen Objektcodetabelle 30 gespeichert, wobei sich die Add-Anweisung an Stelle 194 befindet. Die Stelle der Add-Anweisung innerhalb der neuen Objektcodetabelle 30 (Stelle = 194) wird an der Stelle 130 einer Vorwärtsindextabelle 40 gespeichert. Dies bedeutet, dass das Element, das sich an Stelle 130 der alten Objektcodetabelle 20 befand, sich jetzt an Stelle 194 der neuen Objektcodetabelle 30 befindet. Die Stelle des neuen Codeblocks 35 innerhalb der neuen Objektcodetabelle 30 (Stelle = 188) wird in der Stelle 130 der Vorwärtssteuerindextabelle 50 gespeichert. Dies bedeutet, dass der neue Codeblock, der von dem Element gebildet wurde, der sich an Eintrag 130 der alten Objektcodetabelle 20 befand, sich jetzt an Eintrag 188 der neuen Objektcodetabelle 30 befindet. Die Add-Anweisung enthält keinen Zwischenelement- Offset, so dass nichts in die Tabelle 60 eingegeben wird.
Dieser Zyklus wird jetzt für das nächste Element in der alten Objektcodetabelle 20 wiederholt, "RTS" (Rückkehr von Subroutine) an Stelle 132. Es wird ein neuer Codeblock 37 gebildet, aber es wird festgestellt, dass es keine neuen Anweisungen mit der Rückgabeanweisung einzufügen gibt, also besteht der neue Codeblock 37 nur aus der Rückkehranweisung. Der neue Codeblock 37 wird an der nächsten verfügbaren Stelle in der neuen Objektcodetabelle 30 gespeichert, an Stelle 198. Die Stelle der Rückkehranweisung innerhalb der neuen Objektcodetabelle 30 wird in der Stelle 132 der Vorwärtsindextabelle 40 gespeichert; die Stelle des neuen Codeblocks 37 innerhalb der neuen Objektcodetabelle 30 wird in der Stelle 132 der Vorwärtssteuerindextabelle 50 gespeichert. Da die Rückkehranweisung und der neue Codeblock 37 identisch sind, wird die Nummer 198 in der Stelle 132 beider Indextabellen gespeichert. In diesem Beispiel enthält die Rückkehranweisung keinen Zwischenelement-Offset, so dass in der Zwischenelement-Offsettabelle 60 nichts gespeichert wird. Unbenannte Konstantendaten werden zuweilen zwischen Funktionen, hinter der letzten Anweisung einer Funktion und vor dem nächsten Eintrittspunkt gespeichert; sie können nach Bedarf verarbeitet oder einfach direkt in die neue Objektcodetabelle kopiert werden.
Nach dem Durchführen der Schritte 120-190 für alle Elemente in allen Funktionen wiederholt Schritt 195 den Expansionsprozess der Blöcke 120-190 für alle benannten Daten. Der Expansionsprozess ist für Daten etwas einfacher, weil diese keine Offsets enthalten wie die, die von den Blöcken 160-170 gehandhabt werden. Als Nächstes korrigiert das Expansionsmittel 5 in Schritt 200 die Zwischenelement-Offsets (siehe PATCH.C, "PatchPcRel"). Die Zwischenelement-Offsettabelle wird untersucht, und für jeden Satz von Offset/Basis-Stellen in dieser Tabelle wird der Zwischenelement-Offset korrigiert durch: 1. Addieren des angedeuteten Offsets zu seiner Basis, um zu ermitteln, welches Element in der alten Objektcodetabelle 20 von dem Offset angepeilt wurde; 2. Nachsehen der neuen Stelle des angepeilten Elementes anhand der Vorwärtssteuerindextabelle 50, wenn der Offset für einen Programmsteuertransfer verwendet wird (z. B. ein Sprung oder Abruf), ansonsten Verwenden der Vorwärtsindextabelle 40; 3. Nachschlagen der neuen Stellen von Offset und Basis anhand der Vorwärtsindextabelle 40; und 4. schließlich Korrigieren des Offset in der neuen Objektcodetabelle 30 mit der Differenz zwischen der neuen Stelle des angepeilten Elementes und der neuen Stelle der Basis.
In diesem besonderen Beispiel beinhaltet Schritt 200 das Offset/Basis-Paar 128/126. Der Offset wird an Stelle 128 in Tabelle 20 nachgeschlagen, wo der Wert 6 gefunden wird. Dieser Wert wird zur Basis 126 addiert, so dass sich eine Zielstelle 132 ergibt. Da dieser Offset in einem Programmsteuertransfer- Statement (Abzweigung) verwendet wird, wird die neue Zielstelle in Tabelle 50 nachgeschlagen, so dass sich eine neue Zielstelle 198 ergibt. Die neuen Offset- und Basisstellen werden in Tabelle 40 nachgeschlagen, so dass sich eine neue Basisstelle 182 und eine neue Offsetstelle 184 ergeben. Die Differenz von 198 minus 182, d. h. 16, wird dann an der neuen Offsetstelle 184 gespeichert. Dieser Prozess wird für alle Einträge in Tabelle 60 wiederholt.
Als Nächstes werden, wenn die Objektdatei Symboltabellen oder Verschiebungstabellen enthält, die korrigiert werden müssen, diese in Schritt 201 Element für Element analysiert und durch Ersetzen alter Elementstellen durch neue Elementstellen ersetzt, wie oben erläutert wurde (siehe auch PATCH.C, "PatchTextReloc" und "PatchdataReloc"). Die neuen Elementstellen werden in der Vorwärtsindextabelle 40 nachgeschlagen (mit Ausnahme von Debugging-Symbolen, für die die neuen Stellen in der Vorwärtssteuerindextabelle 50 nachgeschlagen werden). Jetzt wird eine neue Objektcodedatei 1' mit Hilfe der neuen Objektcodetabelle als Daten/Anweisungssektion unter Verwendung der neuen Symbol- und Verschiebungstabellen (falls korrigiert) und unter Verwendung der übrigen Informationen aus der alten Objektdatei 1 geschrieben.

Speicherzugriffsüberwachung

Dieser Aspekt der Erfindung betrifft einen Prozess des Verfolgens von Lese- und Schreibvorgängen von Speicherplatz durch ein Anwendungsprogramm. In der bevorzugten Ausgestaltung werden alle Objektdateien des Anwendungsprogramms durch ein Speichermonitor-Ausstattungsprogramm verarbeitet, das das oben beschriebene Expansionsmittel verwendet, und von dem Daten/Anweisungs-Einfügungsprozess, um einen Funktionsabruf vor jeder Anweisung, die einen Speicherzugriff enthält, und vor einigen Anweisungen einzufügen, die den Stapelzeiger ändern. Dadurch werden alle oder im Wesentlichen alle Speicherzugriffe eines bestimmten Programms (nicht einschließlich der Speicherzugriffe für Anweisungsabrufe) zwecks Durchführung einer Fehlerprüfung überwacht. Alle Objektcodedateien für ein ablauffähiges Programm werden verarbeitet (mit Ausnahme einer Bibliothek von Routinen, die von dem Speichermonitor- Ausstattungsprogramm hinzugefügt werden), und Anweisungen werden zum Ausführen des unten beschriebenen Überwachungsschemas hinzugefügt.
Der allgemeine Ablauf der Implementation eines Überwachungsschemas zur Entdeckung von Fehlern in einem ablauffähigen Programm, indem alle Objektcodedateien für das ablauffähige Programm modifiziert werden, das modifizierte Programm verbunden und dann abgearbeitet wird, ist in Fig. 5 illustriert. Eine erste Objektdatei oder Bibliothek für das ablauffähige Programm wird in Block 300 gewählt. Wenn in Block 310 ermittelt wird, dass die Datei eine einfache Objektdatei anstatt einer Bibliothek ist, dann wird die Objektdatei in Block 320 verarbeitet, um ein Überwachungsschema durch den oben beschriebenen Expansionsprozess zu implementieren; ebenso können die Funktionen innerhalb der Objektdatei wie nachfolgend beschrieben umbenannt werden. Wenn in Block 310 ermittelt wird, dass es sich um eine Bibliothek handelt, dann wird jede Objektdatei, die zu der Bibliothek beiträgt, in Block 330 auf dieselbe Weise verarbeitet, wie eine einfache Objektdatei in Block 320 verarbeitet wird. Dann wird in Block 340 die Bibliothek von den modifizierten Objektdateien neu erstellt. Nach dem Verarbeiten der Objektdatei oder Bibliothek bestimmt Block 350, ob eventuell noch unverarbeitete Dateien für die ablauffähige Datei vorhanden sind. Ist dies der Fall, dann wählt Block 360 eine unverarbeitete Datei, und dann werden die Schritte der Blöcke 310-350 wiederholt. Wenn in Block 350 ermittelt wird, dass alle Dateien für das ursprüngliche ablauffähige Programm verarbeitet sind, dann erfolgt die gesamte notwendige Programmbindung in Block 370, die eine Bindung an eine zusätzliche Bibliotheksdatei einschließlich Funktionen beinhalten kann, die speziell für das Überwachungsschema ausgelegt sind. Das Programm wird dann in Block 380 abgearbeitet; dabei erfolgt die durch den Expansionsprozess hinzugekommene Überwachung.
In der Speicherzugriffsüberwachungsmethode der bevorzugten Ausgestaltung ermittelt der expandierte Code eine Speicherstatusarray mit einem Eintrag für die meisten Speicherstellen, auf die das Programm gültig zugreifen kann, in denen Zwei-Bit-Array-Einträge für jede solche Speicherstelle zugewiesen sind. Jeder Eintrag zeigt den Status der entsprechenden Speicherstelle an, und es gibt die folgenden drei Zustände: (1) unzugewiesen und uninitialisiert (Statusbits = 11); (2) zugewiesen und uninitialisiert (Statusbits = 01); (3) zugewiesen und initialisiert (Statusbits = 00). Vor jeder vorexistierenden Anweisung, die auf Speicherplatz zugreift oder die den Speicherstatus ändern kann, werden zusätzliche Anweisungen addiert, um die Speicherstatusarray aufrecht zu erhalten und um die Speicherstatusarray zum Prüfen auf Fehler in Bezug auf das Schreiben von unzugewiesenem Speicherplatz und das Lesen von uninitialisiertem oder unzugewiesenem Speicherplatz zu verwenden. Fig. 6 zeigt ein Statusübergangsdiagramm und illustriert die drei Zustände, die eine Speicherstelle haben kann und wie Zustände geändert werden. Status (1) wird durch Bezugsziffer 101, Status (2) durch 102 und Status (3) durch 103 angegeben. Das erste Bit eines Statuscodes gibt an, ob die Speicherstelle unzugewiesen ist; das zweite Bit gibt an, ob die Speicherstelle uninitialisiert ist. Speicherstellen in Status 1 können nicht beschrieben oder gelesen werden; die Stellen in Status 2 können beschrieben aber nicht gelesen werden, und diejenigen in Status 3 können beschrieben und gelesen werden.
Statuscodes beginnen im Allgemeinen mit 11 (Status 1, unzugewiesen) und ändern sich während der Ausführung des modifizierten Anwendungsprogramms wie folgt: bei einem erfolgreichen Aufruf an "malloc" (eine c- Speicherzuweisungsroutine) sind die Statusbits für jedes Byte auf 01 gesetzt; bei einem erfolgreichen Aufruf an "free" sind die Statusbits für jedes Byte auf 11 gesetzt; bei einem erfolgreichen Aufruf an "realloc" sind die Statusbits für den alten Speicher auf 11 und für den neuen auf 01 gesetzt (die Bits für diesen Teil des neuen Speicherplatzes, der vom alten Speicherplatz initialisiert wurde, sind auf 00 gesetzt). Wenn 1 der Stapelzeiger dekrementiert wird, werden die Statusbits für die Bytes auf dem jetzt zugewiesenen Stapel auf 01 gesetzt. Unmittelbar vor dem Schreiben eines Bytes wird das erste Bit seiner Statusbits geprüft - wenn das Bit gesetzt ist, wird ein Fehler signalisiert, ansonsten wird das lesbare Bit gelöscht (da das Byte jetzt initialisiert wird). Ebenso wird, kurz bevor ein Byte gelesen werden soll, das zweite Bit seiner Statusbits geprüft - wenn das Bit gesetzt ist, wird ein Fehler signalisiert. Ein spezieller Fall ist, kurz bevor ein Byte von einer Speicherstelle auf eine andere kopiert werden soll, wird das Lesen von uninitialisiertem Speicherplatz zugelassen, aber das Ziel wird als uninitialisiert markiert, so dass ein Kopiervorgang an einer Struktur mit uninitialisierten Bytes wie z. B. solche von Compiler-Padding keine Fehlersignalisierung verursacht. In der bevorzugten Ausgestaltung wird die Statusprüfung und -änderung durch eine Gruppe von speziellen Laufzeitfunktionen gehandhabt, die an den entsprechenden Punkten abgerufen werden.
Fig. 7 repräsentiert den gesamten virtuellen 32-Bit- Adressraum und ist nicht maßstabsgetreu. Die Speicherregion 300 am Fuß des Adressraums, die den statischen Informationen in dem Programm entspricht, beginnt und bleibt in Status 3. Die Speicherregion 300 enthält die Anweisungscodes 301, die Daten 302 und die BSS-Daten 303 (Datenlader - auf null initialisiert). Die Bytes im Haufen 400, die über die Funktionen malloc, realloc und free manipuliert werden, ändern ihren Zustand häufig. Dieser Speicherplatz ist zum Starten in Status 1, geht dann in Status 2, wenn er der malloc-Funktion unterzogen wird, und dann nach dem Schreiben in Status 3; wenn er befreit ist (free), geht er zurück in Status 1. Die Speicherregion 500 ist für den Stapel verfügbar. Speicher 500 ist in Status 1, wenn er sich unter dem Stapelzeiger befindet. Wenn sich der Stapelzeiger abwärts bewegt, werden Teile dieses Speicherplatzes "zugewiesen" (allocated) und befinden sich in Status 2. Wenn der Stapel beschrieben ist, geht der Speicherplatz zurück in Status 3. Wenn sich der Stapelzeiger aufwärts bewegt, geht der Speicherplatz zurück in Status 1. Man könnte jeden Augenblick des Stapelzeigers als Zuweisung oder Zuweisungsaufhebung behandeln und dieselben Routinen aufrufen, die auch für malloc und free aufgerufen werden. Dies verursacht jedoch eine erhebliche Leistungsherabsetzung, weil sich der Stapelzeiger häufig ändert. Eine vereinfachte Weise zum Verfolgen des Status von Speicherplatz in dieser Region mit weniger Statusbitführung besteht darin, die Stelle des referenzierten Speicherplatzes mit dem Stapelzeiger zu vergleichen. Speicherplatz in dieser Region und oberhalb des Stapelzeigers wird in der Statusbittabelle nachgeschlagen; Speicherplatz in dieser Region und unterhalb des Stapelzeigers wird als in Status 1 befindlich angesehen. Gemäß der bevorzugten Ausgestaltung werden Stapelzeiger wie folgt gehandhabt: (a) Nach dem Eintritt in eine Funktion, wo eine Link-Anweisung Stapelraum für die lokalen Variablen der Funktion zuweist, wird ein Aufruf zum Markieren dieses betroffenen Speicherplatzes als Status 2 eingefügt. (b) Wenn ein Argument auf den Stapel geschoben wird, wird ein Aufruf zum Markieren des betroffenen Speicherplatzes als Status 3 eingefügt. (c) Wenn der Stapelzeiger inkrementiert wird (um Stapelraum zurückzugewinnen), geschieht nichts. Dies ist an die Methode zum Nachschlagen der Statusbits für ein bestimmtes Byte gebunden, die die Regel "wenn das Byte auf dem Stapel, aber unter dem Stapelzeiger ist, die Bit-Tabelle ignorieren und die Bits mit Status 1 (unzugewiesen) verwenden" angewendet. (d) Aufrufe an "alloca" werden speziell gehandhabt, und der betroffene Speicherplatz wird auf Status 2 gesetzt.
Es gibt eine zusätzliche Komplikation für Stapelvariablen. Optimierungscompiler ordnen Code um, um die Leistung zu erhöhen; eine der von ihnen vorgenommenen Optimierungen besteht darin, einfache Zuweisungen aus Schleifen hinaus zu bewegen. Dies kann zuweilen zu einem Zugriff auf eine uninitialisierte Stapelvariable führen, aber das Ergebnis wird nicht verwendet. Leider würde ein überwachtes Programm nicht ermitteln, dass das Ergebnis nicht verwendet wird, und würde einen Fehler signalisieren. Eine solche unnötige Fehlersignalisierung wird dadurch vermieden, dass uninitialisierte Stapelvariablenprüfungen in optimiertem Code durch Markieren lokaler Variablen in dem optimierten Stapelrahmen als initialisiert (d. h. in Zustand 3) gesperrt wird.
Die Statusbits für den Speicherplatz von 0 bis zur Oberseite des Haufens 400 werden in einer ersten Bit-Array gehalten; die Statusbits für Stapelspeicherplatz 500 werden in einer zweiten Bit-Array gehalten. Virtueller Speicherplatz außerhalb der Speicherregionen 300, 400 und 500 wird zum Speichern dieser Bit-Arrays mit Hilfe des "mmap" Systemrufs erhalten. Zum Finden der Statusbits für ein willkürliches Byte an einer Adresse wird die folgende Methode angewendet: wenn sich die Adresse unter dem oberen Ende des Haufens 400 befindet, ist der Bitindex das Zweifache der Adresse; wenn sich die Adresse in der Stapelspeicherregion 500 befindet, ist der Bit-Index die Adresse minus der Adresse des unteren Endes der Stapelregion 500, dann multipliziert mit 2; ansonsten muss die Adresse eine spezielle Adresse sein, wie z. B. gemeinsamer Speicher, und wird ignoriert.
Der aktuelle Zustand einer Speicherstelle könnte ohne Verwendung von Statusarrays angedeutet werden. Der an einer Speicherstelle gespeicherte Wert würde den Status dieser Stelle anzeigen. Ein bestimmter Wert würde den unzugewiesenen Zustand (Status 1) repräsentieren, ein anderer Wert würde den zugewiesenen und uninitialisierten Zustand (Status 2) repräsentieren, alle anderen Werte würden Benutzerdaten in Status 3 repräsentieren. Einzelbyte-Werte haben jedoch natürlich keinen signifikanten Bereich, so dass die die Zustände 1 und 2 repräsentierenden Werte häufig in gültigen Benutzerdaten auftreten würden, so dass fälschlicherweise Fehler signalisiert würden. Dieses Problem würde durch die Verwendung von Zwei- oder Vier-Byte-Sequenzen minimiert, um Speicherzustände anzuzeigen, was die Chancen eines zufälligen Auftretens reduziert, aber eine Einzelbyte-Zugriffsprüfung würde dann nicht ohne weiteres unterstützt. Aus diesem Grund wird die Verwendung von einer oder mehreren separaten Statusarrays als bevorzugt angesehen.
Der Code für Betriebssystemroutinen wird nicht in das Benutzerprogramm eingebunden. Dieser Code steht damit erfindungsgemäß nicht für die Verarbeitung zur Verfügung, und der Speicherstatus-Überwachungscode kann nicht eingefügt werden. Aus diesem Grund muss der Überwachungsprozess spezielle Maßnahmen zum Verfolgen von Systemaufrufen ergreifen, in denen das Betriebssystem direkt auf den Programmspeicher zugreift. Dieselben besonderen Maßnahmen werden auch zum Verfolgen von Haufenmanagementfunktionen "malloc", "free" und "realloc" ergriffen.
Diese Sonderfunktionen sind in Fig. 8 dargestellt, die einen Prozess zum Abfangen aller Rufe zu einem bestimmten Satz von Funktionen zeigt, indem der Name jeder Definition (gewöhnlich gibt es nur eine) dieser Funktionen modifiziert wird und deren alte Namen durch neue Namen ersetzt werden. Dann werden Interceptor-Funktionen unter den alten Namen bereitgestellt; diese Interceptor-Funktionen rufen gewöhnlich die abgefangenen Funktionen auf und haben einen anderen Code. Bei einem Funktionsnamen, f, und seinem gewünschten Ersatz, F, der keine größere Stringlänge haben darf als f, wird jede Objektdatei auf externe Symbole (Typen N_TEXT und N_EXT) mit der Bezeichnung f abgetastet. Für jeden solchen Fall wird der Name F über den Namen f geschrieben. Wenn der Linker läuft, ist die einzige Definition von f die Interceptor-Funktion, und wenn das Programm abläuft, wird die Interceptor-Funktion f anstelle des ursprünglichen f aufgerufen, das in F umbenannt wurde. Um zu unterstützen, dass der Name von F länger ist als f, kann die String-Tabelle kopiert und erweitert werden, und dann werden alle alten Referenzen, die sich in der Symbolsektion befanden, in die neue String-Tabelle gesetzt.
In der bevorzugten Ausgestaltung werden die Datensektionen der Objektcodedateien mit zusätzlichen Dummy-Einträgen zwischen jedem Datenelement oder jeder Datenarray expandiert. Diese zusätzlichen Einträge erhalten den Status unzugewiesen und uninitialisiert und unterstützen die Erkennung von Array- Grenzverletzungen und ähnlichen Datenfehlern. Die bevorzugte Ausgestaltung ermittelt auch eine Liste von Speicher- oder Datenelementstellen, die Watchpoints sein sollen, mit denen eine umfassende Überwachung durchgeführt werden soll. Diese zusätzlichen Aspekte der bevorzugten Ausgestaltung werden nachfolgend ausführlicher beschrieben.
Um viele Array-Grenzverletzungen zu erkennen, werden 8 Byte Speicherplatz vor und hinter jeder Array in den Haufen-, Daten- und bss-Segmenten zugewiesen. Diese 8 Bytes werden als Status 1 (unzugewiesen) markiert, so dass dann, wenn das Programm auf Stellen hinter dem Ende einer Array zugreift, es auf Speicherplatz mit Status 1 zugreift und die Signalisierung eines Fehlers auslöst. Für Haufen-Arrays werden die Statusbits gesetzt, wenn die Array zugewiesen ist. Für statisch zugewiesene Arrays wird ein spezieller 8-Byte-Wert (der wohl kaum zufällig auftritt) zwischen jedes statisch zugewiesene Datenelement eingefügt. Wenn das überwachte Programm die Ausführung beginnt, wird der statisch zugewiesene Speicherplatz auf Auftretensfälle des 8-Byte-Wertes hin untersucht. Die Statusbits für jedes solche Auftreten werden auf Status 1 gesetzt. Die Fehlersignalisierungsroutine sucht nach den speziellen 8-Byte-Werten, um informativere Meldungen zu drucken ("Array-Grenzverletzung" anstatt "Speicherzugriffsverletzung"). Stapelarrays sind derzeit nicht mit den 8-Byte-Markern begrenzt, obwohl dies bei Bedarf geschehen könnte.
Mit dieser Methode des Verfolgens von Arrays sind jedoch weitere Komplikationen verbunden. Gelegentlich errechnet der Compiler oder der Programmierer die Adresse des Endes einer Array und benutzt sie als Obergrenzenzeiger. Wenn die Array in demselben Dateiobergrenzenzeiger verwendet wird, ist die von dem Compiler gegebene Verschiebungsinformation mit derjenigen identisch, die für eine Referenz auf den Anfang der nächsten Array bereitgestellt wird. Im Allgemeinen könnte jede Link- Zeit-Referenz auf eine Adresse zwischen zwei Daten entweder zum Ende des ersten Datenelementes oder zum Beginn des zweiten beabsichtigt werden. Wenn die Daten getrennt sind, wie im vorangegangenen Absatz beschrieben wurde, dann sind diese beiden Punkte nicht mehr identisch. Die Referenz erfolgt nahezu immer auf den Beginn des zweiten Elementes, und somit kann diese Annahme gemacht werden. Es kann jedoch eine Prüfung durchgeführt werden, um zu ermitteln, ob die Referenz lediglich als Obergrenzenzeiger verwendet wird oder nicht, und die Referenz kann entsprechend korrigiert werden. Eine weitere Alternative besteht darin, es dem Programmierer zu erlauben, die Einfügung des 8-Byte-Datenseparators in Dateien zu unterdrücken, die einen Obergrenzenzeiger für örtlich definierte Arrays verwenden.
Watchpoints werden dadurch implementiert, dass die Lese- und Schreibstatusbits der zu überwachenden Bytes auf 11 (binär) gesetzt werden und die Stelle des Watchpoint in eine Watchpoint-Liste gesetzt wird. Bei einem Aufruf an die Fehlersignalisierungsroutine wird die geprüfte Adresse mit der Liste aktueller Watchpoints verglichen. Gibt es keine Übereinstimmung, dann wird die Fehlersignalisierungsroutine normal fortgesetzt. Gibt es eine Übereinstimmung, dann befinden sich die zu manipulierenden Statusbits in einer Watchpoint spezifischen Datenstruktur, und die Fehlerroutine ruft die Watchpoint-Routine ab, die typischerweise eine Meldung druckt und ohne Signalisieren eines Fehlers zurückkehrt.
Die oben beschriebene Speicherzugriffsüberwachung der bevorzugten Ausgestaltung wird durch die in den Fig. 4 und 5 illustrierten Methoden implementiert, wobei die Bildung neuer Codeblocks, Schritt 130 von Fig. 4, gemäß der nachfolgend beschriebenen Methode mit Bezug auf Fig. 10 durchgeführt wird, und wobei Funktionsdefinitionen von Betriebssystemroutinen, die auf Speicherplatz zugreifen, wie oben beschrieben abgefangen werden. Ebenso wird der ursprüngliche Anfangseintrittspunkt in das Programm als Punkt zum Überwachen von Setup-Code umdefiniert, der am Ende auf den ursprünglichen Anfangseintrittspunkt übertragen wird. Der Überwachungs-Setup- Code ist somit der erste Code, der in dem modifizierten ablauffähigen Programm ausgeführt wird, und ermittelt die Speicherstatus-Arrays.
Bezugnehmend auf Fig. 10, für diese Bildung neuer Codeblöcke bestimmt Block 130.1 die Verarbeitung des Elementes je nach dem, ob es sich um eine Anweisung (Teil einer Funktion) oder um ein Datenelement handelt. Handelt es sich um ein Datenelement, dann kopieren die Blöcke 130.2 bis 130.4 das Datenelement in den neuen Codeblock mit einem Dummy-Eintrag davor und dahinter, um die oben beschriebene Array-Grenzprüfung zu ermöglichen. Für Anweisungen wird in Block 130.5 ermittelt, ob sie auf Speicherplatz zugreifen. Ist dies der Fall, dann fügt Block 130.6 eine Anweisung hinzu, die auf den Stapel der Speicheradresse(n) geschoben wird, auf die zugegriffen werden soll, und Block. 130.7 fügt einen Aufruf an die geeignete spezielle Laufzeitfunktion hinzu, die die richtigen Statusbits prüft und setzt, Fehler signalisiert und Watchpoints handhabt. Schließlich wird in Block 130.8 das Element selbst (die vorexistierende ursprüngliche Anweisung) in die neue Objektcodetabelle kopiert, und Schritt 130 zum Bilden des neuen Codeblocks 130 wird abgeschlossen. Der Rest der Methode des Modifizierens des ablauffähigen Programms und des Überwachens seines Ablaufs ist wie oben mit Bezug auf die Fig. 4 und 5 beschrieben.

Alternative Ausgestaltungen

Die zum Implementieren der Überwachung verwendeten Anweisungen könnten anstatt durch Objektcodeverarbeitung auf eine Compiler-gestützte oder Precompiler-gestützte Weise hinzugefügt werden, jedoch jeweils mit einigen Vorteilen und erheblichen Nachteilen. Ein Compiler erzeugt normalerweise während der Kompilation alle notwendigen Informationen zum Durchführen dieser Überwachung; was jedoch grundsätzlich fehlt, ist, dass der Compiler zusätzlichen Code hinzufügt, wie in Fig. 10 illustriert ist. Die Nachteile dieses Ansatzes bestehen darin, dass die Neukompilation für die Fehlerprüfung weitaus mehr Zeit in Anspruch nimmt als die oben beschriebene Objektcodeverarbeitung und dass ein Source-Code-Zugriff auf alle beteiligten Bibliotheken notwendig ist, um eine umfassende und genaue Fehlerprüfung zu gewährleisten. Ein Precompilergestützter Ansatz, der zusätzliche Source-Code-Statements in Source-Code-Dateien einfügen würde, hätte alle Nachteile eines Compiler-gestützten Ansatzes, obwohl er auch Portabilitätsvorteile hätte.
Ein weiterer alternativer Ansatz wäre der, dass die Erfindung den Überwachungscode direkt in ein zuvor verbundenes Programm einfügt. Da ein ablauffähiges Programm dasselbe Grundformat hat wie eine Relativobjektdatei, könnte das Programm als eine einzige größe Objektdatei verarbeitet werden. Dies würde eine stärker involvierte Totcode-Analyse erfordern, um Daten von Anweisungen zu unterscheiden, und es gäbe sowohl relative als auch absolute Adressen, die aktualisiert werden müssten, anstatt nur relative Adressen (Offsets).
Es ist zu verstehen, dass die obige Beschreibung lediglich illustrativ und nicht begrenzend ist. Für die Fachperson werden nach einem Studium der obigen Beschreibung viele weitere Ausgestaltungen offensichtlich werden. So könnten beispielsweise Vorkehrungen für einen gemeinsam genutzten Speicher betroffen werden, wie z. B. mit noch einer weiteren Bit-Tabelle, aber auch die Bit-Tabellen sollten dann gemeinsam genutzt werden, und alle Programme, die auf den gemeinsam genutzten Speicherplatz zugreifen, sollten die Statuscodes korrekt führen. Ebenso wäre ein weiteres Beispiel für ein Überwachungsschema, das für die Implementation durch die obige Objektcodeexpansion besonders geeignet wäre, eine Standardprofilierung. Der Umfang der Erfindung ist somit unter Bezugnahme auf die beiliegenden Ansprüche zu sehen, zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind.

Claims

1. Verfahren zum Signalisieren von Fehlern im Speicherzugriff durch ein Computerprogramm, wobei das genannte Verfahren folgendes umfasst: Empfangen eines ersten, das genannte Computerprogramm bildenden Satzes von Maschinenanweisungen (1) als Eingang, wobei der genannte erste Satz von Maschinenanweisungen wenigstens eine Speicherzugriffsanweisung (33) zum Zugreifen auf eine Speicherstelle beinhaltet, wobei das Verfahren durch den folgenden Schritt gekennzeichnet ist: Expandieren des genannten ersten Satzes von Maschinenanweisungen zum Generieren (5) eines zweiten Satzes von Maschinenanweisungen (1'), wobei der genannte Satz von Maschinenanweisungen wenigstens eine zusätzliche Speicherüberwachungsanweisung (35) beinhaltet, deren Aufgabe es ist, Speicherstatusinformationen in Verbindung mit der Speicherstelle zu prüfen, auf die durch die genannte Speicherzugriffsanweisung zugegriffen werden soll, und einen Fehler zu signalisieren, wenn die Speicherstatusinformation nicht mit der Speicherzugriffsanweisung für die genannte Speicherstelle übereinstimmt.

2. Verfahren nach Anspruch 1, bei dem dem Computerprogramm wenigstens eine Speicherüberwachungsanweisung an einer Stelle hinzugefügt wird, so dass sie jedes Mal dann ausgeführt wird, wenn die Speicherzugriffsanweisung ausgeführt wird.

3. Verfahren nach Anspruch 1 oder 2, bei dem die Speicherstatusinformation einen zugewiesenen Zustand und einen unzugewiesenen Zustand der Speicherstelle anzeigen kann; wobei ein Fehler signalisiert wird, wenn die genannte Speicherstatusinformation anzeigt, dass sich die genannte Speicherstelle in einem unzugewiesenen Zustand befindet.

4. Verfahren nach einem der vorherigen Ansprüche, bei dem die genannten Speicherzugriffsanweisungen eine Leseanweisung zum Lesen aus einer Speicherstelle beinhalten und wobei die genannte Speicherstatusinformation einen zugewiesenen-und- uninitialisierten Zustand (102) und einen zugewiesenen-und- initialisierten Zustand (103) anzeigen kann; wobei ein Fehler signalisiert wird, wenn die Speicherstatusinformation anzeigt, dass sich eine Speicherstelle, auf die durch eine Leseanweisung zugegriffen werden soll, in einem zugewiesenen- und-uninitialisierten Zustand befindet.

5. Verfahren nach einem der vorherigen Ansprüche, ferner umfassend das Verwalten der Speicherstatusinformation für die genannte Speicherstelle.

6. Verfahren nach einem der vorherigen Ansprüche, bei dem die genannten zusätzlichen Speicherüberwachungsanweisungen zu dem zweiten Satz von Anweisungen mit Hilfe eines Verfahrens hinzugefügt werden, das die folgenden Schritte umfasst:

a) Bereitstellen einer alten Objektcodetabelle (20), die den ersten Satz von Anweisungen beinhaltet;

b) Bereitstellen einer neuen Objektcodetabelle (30), einer Zwischenelement-Offsettabelle (60), einer Vorwärtsindextabelle (40), einer Vorwärtssteuerindextabelle (50), wobei die genannten Tabellen zur Speicherung von Elementen dienen, wobei die genannten Elemente Stellen innerhalb der Tabellen haben;

c) Ausführen der folgenden Schritte für jedes Element in der alten Objektcodetabelle:

i) Speichern eines neuen Codeblocks in der neuen Objektcodetabelle, wobei der genannte neue Codeblock die zusätzlichen Speicherüberwachungsanweisungen und das Element umfasst;

ii) Speichern der Stelle des Elementes innerhalb der neuen Objektcodetabelle in der Vorwärtsindextabelle;

iii) Speichern der Stelle des neuen Codeblocks innerhalb der neuen Objektcodetabelle in der Vorwärtssteuerindextabelle; und

iv) für einen Zwischenelementoffset enthaltende Elemente, Anzeigen des Offsets in der Zwischenelement- Offsettabelle; und

d) für jeden in der Zwischenelement-Offsettabelle angezeigten Zwischenelement-Offset, Aktualisieren des Zwischenelement-Offset anhand der Vorwärtssteuerindextabelle für die Zwischenelement-Offsets, die für eine Programmsteuerübertragung sind, und ansonsten anhand der Vorwärtsindextabelle.

7. Verfahren nach einem der vorherigen Ansprüche, bei dem der erste und der zweite Satz Anweisungen Objektcode sind.

8. Computersystem, umfassend ein Speichermittel mit wenigstens einer Speicherstelle; und einen Prozessor, der die Aufgabe hat, einen ersten Satz von Maschinenanweisungen (1) als Eingang zu empfangen, wobei der genannte erste Satz von Maschinenanweisungen eine Speicherzugriffsanweisung (33) zum Zugreifen auf die wenigstens eine Speicherstelle beinhaltet; wobei das System dadurch gekennzeichnet ist, dass es folgendes umfasst: ein Mittel (5) zum Expandieren des genannten ersten Satzes von Maschinenanweisungen zum Generieren eines zweiten Satzes von Maschinenanweisungen (1'), wobei das Mittel zum Expandieren des zweiten Satzes von Maschinenanweisungen die Aufgabe hat, zusätzliche Speicherüberwachungsanweisungen (35) zu generieren, die die Aufgabe haben, Speicherstatusinformationen in Verbindung mit der wenigstens einen Speicherstelle zu prüfen, auf die durch die genannte Speicherzugriffsanweisung zugegriffen werden soll, und einen Fehler zu signalisieren, wenn die Speicherstatusinformation nicht mit der Speicherzugriffsanweisung für die genannte wenigstens eine Speicherstelle übereinstimmt.

9. Computersystem nach Anspruch 8, bei dem die genannte wenigstens eine Speicherüberwachungsanweisung zu dem genannten ersten Satz von Maschinenanweisungen an einer Stelle hinzugefügt wird, so dass sie jedes Mal ausgeführt wird, wenn die Speicherzugriffsanweisung ausgeführt wird.

10. Computersystem nach Anspruch 8 oder 9, bei dem die Speicherstatusinformation einen zugewiesenen Zustand und einen unzugewiesenen Zustand der Speicherstelle anzeigen kann; wobei ein Fehler signalisiert wird, wenn die genannte Speicherstatusinformation anzeigt, dass sich die genannte Speicherstelle in einem unzugewiesenen Zustand befindet.

11. Computersystem nach einem der Ansprüche 8 bis 10, bei dem die genannten Speicherzugriffsanweisungen eine Leseanweisung zum Lesen von einer Speicherstelle beinhalten und wobei die genannte Speicherstatusinformation einen zugewiesenen-und-uninitialisierten Zustand (102) und einen zugewiesenen-und-initialisierten Zustand (103) anzeigen kann, wobei ein Fehler signalisiert wird, wenn die Speicherstatusinformation anzeigt, dass sich eine Speicherstelle, auf die durch eine Leseanweisung zugegriffen werden soll, in einem zugewiesenen-und-uninitialisierten Zustand befindet.

12. Computersystem nach einem der Ansprüche 8 bis 11, bei dem der Prozessor ein Mittel beinhaltet, das die Aufgabe hat, die Speicherstatusinformation zu verwalten.

13. Computersystem nach einem der Ansprüche 8 bis 12, bei dem der erste und der zweite Satz Anweisungen Objektcode sind.

14. Computerprogramm, das die Aufgabe hat, einen ersten Satz von Maschinenanweisungen (1) als Eingang zu empfangen, wobei der genannte erste Satz von Maschinenanweisungen eine Speicherzugriffsanweisung (33) zum Zugreifen auf eine Speicherstelle beinhaltet, und das dadurch gekennzeichnet ist, dass es die Aufgabe hat, den genannten ersten Satz von Maschinenanweisungen zum Generieren eines zweiten Satzes von Maschinenanweisungen (1') zu expandieren, der zusätzliche Speicherüberwachungsanweisungen (35) beinhaltet, die die Aufgabe haben, die Speicherstatusinformation in Verbindung mit der Speicherstelle zu prüfen, auf die durch die genannte Speicherzugriffsanweisung zugegriffen werden soll, und um einen Fehler zu signalisieren, wenn die Speicherstatusinformation nicht mit der Speicherzugriffsinformation für die genannte Speicherstelle übereinstimmt.

15. Computerprogramm nach Anspruch 14, das die Aufgabe hat, wenigstens eine zusätzliche Speicherüberwachungsanweisung zum ersten Satz von Maschinenanweisungen an einer Stelle hinzuzufügen, so dass sie jedes Mal ausgeführt wird, wenn die Speicherzugriffsanweisung ausgeführt wird.

16. Computerprogramm nach Anspruch 14 oder 15, bei dem die Speicherstatusinformation einen zugewiesenen Zustand und einen unzugewiesenen Zustand der Speicherstelle anzeigen kann, wobei ein Fehler signalisiert wird, wenn die genannte Speicherstatusinformation anzeigt, dass sich die genannte Speicherstelle in einem unzugewiesenen Zustand befindet.

17. Computerprogramm nach einem der Ansprüche 14 bis 16, bei dem die genannten Speicherzugriffsanweisungen eine Leseanweisung zum Lesen von einer Speicherstelle beinhalten, und wobei die genannte Speicherstatusinformation einen zugewiesenen-und uninitialisierten Zustand (102) und einen zugewiesenen-und-initialisierten Zustand (103) anzeigen kann, wobei ein Fehler signalisiert wird, wenn die Speicherstatusinformation anzeigt, dass sich eine Speicherstelle, auf die durch eine Leseanweisung zugegriffen werden soll, in einem zugewiesenen-und uninitialisierten Zustand befindet.

18. Computerprogramm nach einem der Ansprüche 14 bis 17, das die Aufgabe hat, die Speicherstatusinformation für die genannte Speicherstelle zu verwalten.

19. Computerprogramm nach einem der Ansprüche 14 bis 18, bei dem die genannten zusätzlichen Speicherüberwachungsanweisungen zum zweiten Satz von Anweisungen mit Hilfe eines Verfahrens hinzugefügt werden, das die folgenden Schritte umfasst:

a) Bereitstellen einer alten Objektcodetabelle (20), die den ersten Satz von Anweisungen enthält;

c) Durchführen der folgenden Schritte für jedes Element in der alten Objektcodetabelle:

iii) Speichern der Stelle des neuen Codeblocks innerhalb der neuen Objektcodetabelle in der Vorwärtssteuertabelle; und

iv) für einen Zwischenelement-Offset enthaltende Elemente, Anzeigen des Offset in der Zwischenelement- Offsettabelle; und

d) für jeden in der Zwischenelement-Offsettabelle angezeigten Zwischenelement-Offset, Aktualisieren des Zwischenelement-Offsets anhand der Vorwärtssteuerindextabelle für die Zwischenelement-Offsets, die für eine Programmsteuerübertragung sind, und ansonsten anhand der Vorwärtsindextabelle.

20. Computerprogramm nach einem der Ansprüche 14 bis 19, bei dem der erste und der zweite Satz Anweisungen Objektcode sind.

21. Computerspeichermedium, auf dem ein Computerprogramm aufgezeichnet ist, das die Aufgabe hat, Fehler im Speicherzugriff durch dieses zu signalisieren, wobei das Computerprogramm die folgende Aufgabe hat: Empfangen eines ersten Satzes von Maschinenanweisungen (1) als Eingang, wobei der genannte erste Satz von Maschinenanweisungen eine Speicherzugriffsanweisung (33) zum Zugreifen auf eine Speicherstelle beinhaltet, und dadurch gekennzeichnet, dass es die folgende Aufgabe hat: Expandieren des genannten ersten Satzes von Maschinenanweisungen zum Generieren eines zweiten Satzes von Maschinenanweisungen (1'), der zusätzliche Speicherüberwachungsanweisungen (35) beinhaltet, die die Aufgabe haben, die Speicherstatusinformation in Verbindung mit der Speicherstelle zu prüfen, auf die von der genannten Speicherzugriffsanweisung zugegriffen werden soll, und einen Fehler zu signalisieren, wenn die Speicherstatusinformation nicht mit der Speicherzugriffsanweisung für die genannte Speicherstelle übereinstimmt.