Trace-Werkzeuge kehren des Innerste des Prozessors nach außen
Prozessoren umkrempeln
Fortsetzung des Artikels von Teil 3
Open Source als Abhilfe?
Bei Open-Source-Software hat man Zugriff auf den Quellcode. Dieser mag zwar Einblicke in die Absichten des Software-Entwicklers vermitteln, bietet jedoch wenig Informationen über die dynamischen Charakteristika des Codes. Betrachten Sie das Beispiel im Listing. Welcher Speicher wird durch den Code angesprochen? Wie lange braucht das Programm zu seiner Ausführung? Wie tritt es mit dem Rest des Systems in Wechselwirkung? Treten irgendwelche Race-Bedingungen auf? Wie wird es unrichtige Parameter verarbeiten? Wie wird es sich nach einer unerwarteten Exception, einem DMA-Ereignis oder einem zwischenzeitlichen Taskwechsel verhalten? Ist diese Funktion exakt und konsistent?
Diese und andere Fragen sind nur schwer allein durch Quellcode-Analyse zu beantworten, unabhängig von der Zahl von Ingenieuren, die den Code in verschiedenen Projekten implementiert haben.
Die Chipdesigner, die bisher Fortschritte der Halbleitertechnik nach dem Moore’schen Gesetz gewohnt waren, werden derzeit durch die Grenzen der physikalischen Geometrie und der Verlustleistung herausgefordert. In ähnlicher Weise bildet die Software-Komplexität ein Hindernis für die Software-Entwickler. Die Verarbeitungsfähigkeit lässt sich nicht beliebig steigern, weil einfach der Überblick verlorengeht. Einfach ausgedrückt, ist es sehr schwer, Probleme zu beheben, die man nicht beobachten kann, die nur unregelmäßig auftreten oder deren Ursache im Moment des Auftretens nicht mehr existiert.
Die Aufzeichnung des Programmablaufs in Echtzeit (RTT – Real-Time Trace) stellt sich mehr und mehr als Ideallösung für die fehlende Einsicht in die Software-Ausfüh- rung heraus. Zwar ist Echtzeit-Trace (siehe Kasten) bereits seit mehr als 20 Jahren ein übliches Verfahren, doch wiesen frühe Trace-Tools nur kleine Speichermengen auf – bestenfalls wenige Kilobyte. Dies schränkte ihren Einsatz auf die Erfassung bekannter, kurzzeitig auftretender Probleme auf Maschinensprach-Ebene ein, und häufig musste der Entwickler komplexe Trigger setzen, um den interessierenden Bereich zu erfassen. Das ließ Echtzeit-Trace eher zu einem Spezial-Tool werden und nicht zu einem einfachen Werkzeug des täglichen Software-Debugging.
Jobangebote+ passend zum Thema
Echtzeit-Trace – eine alte Lösung wird erwachsen
Eine der jüngsten Neueinführungen von Trace-Probes hoher Kapazität und unterstützender Tools hat die Einsatzmöglichkeiten von Echtzeit-Trace in der Software-Entwicklung stark erweitert. Ähnlich einem digitalen Videorecorder erfassen diese Entwicklungssysteme Milliarden von Prozessorzyklen und erlauben es, das Programm anschließend vorwärts und rückwärts „abzuspielen“. Hochentwickelte Visualisierungs-Tools sorgen für ein klares Bild darüber, was im Quellcode, auf dem Call-Stack oder auf Thread-Ebene geschehen ist. Tools zur detaillierten Timing-Analyse können rasch Code- und Speicher-Engpässe identifizieren und so Hinweise zur Optimierung anbieten. Tools zur statistischen Analyse tragen mit Leichtigkeit zum Auffinden kurzzeitig auftretender Bugs oder von anormalen Programmverzweigungen bei (Bild 1).
Diese Debugging-Systeme führten zu einer Veränderung der Denkweise in der Software-Entwicklung. Es ist wesentlich effektiver, so viele Trace-Daten wie möglich zu sammeln und sich die Leistung eines Desktop-PCs zum Auffinden von Fehlern zunutze zu machen, als einen Ingenieur zu beauftragen, manuell nach ihnen zu suchen, um dann komplizierte Triggerbedingungen in den Code einzubauen. Es gibt keine Obergrenze für die benötigte Trace-Speicherkapazität.
- Prozessoren umkrempeln
- Prozessoren umkrempeln
- Trace-Ports und Prozessoren
- Open Source als Abhilfe?
