Bild 1: Die System Studio Architektur von Intel.

Bild 1: Die System Studio Architektur von Intel.Intel

JTAG-Debugger und JTAG-Interface helfen dem Systementwickler effizient bei der Softwarefehlersuche in hardwarenaher Software (Treiber, BIOS, Peripherie) in den embedded und mobilen Atom-Prozessoranwendungen. Die JTAG-Funktionalität adressiert unter anderem die Softwareentwicklung von Silicon-on-Chip (SoC).

Die nachfolgend beschriebenen Einzelkomponenten des System-Studio-Gesamtpakets sind auch in die Eclipse-Entwicklungsumgebung C/C++ Development Tooling (CDT)integrierbar und können von dort aus genutzt werden. Es stehen aber auch Command-Line basierende Versionen oder in einem eigenen Fenster laufende Versionen der Komponenten in einem Windows-Host (Windows 7) zur Verfügung. Die System-Suite-Werkzeuge umfassen folgende Komponenten:

Auf einen Blick

Intel offeriert seit einigen Jahren Komplettpakete von Softwareentwicklungstools wie Parallel Studio XE und Cluster Studio XE. Diese Suites sind für Applikationsentwickler gedacht, die für die High-end-Prozessoren Xeon- und Core-Architektur und Xeon-Coprozessoren (MIC-Architektur) Anwendungen schreiben und austesten und dabei Shared Memory-, Distributed Memory-Systeme oder auch hybride Systeme nutzen.

  • Der Intel C/C++-Compiler ist binär und Quell-Code-kompatibel mit den GNU GCC-Compilern und anderen Cross-Compilern. Er unterstützt diverse Parallelisierungsmethoden wie OpenMP als auch Cilk Plus. Cilk Plus ist C++-Erweiterung, die Task-Parallelisierungskonstrukte und SIMD (Single Instructrion Multiple Data) nutzende Strukturen wie etwa Array Annotation unterstützt.
  • Mit Intels Performance Primitives (IPP) steht eine Thread-Safe-Bibliothek für Medienapplikationen zur Verfügung. IPP umfasst viele Funktionen, die im Embedded-Umfeld häufig zur Anwendung kommen. Dazu gehören vor allem ein- und zweidimensionale signalverarbeitende Funktionen wie beispielsweise Filter, Statistik, Bildverarbeitung (MP3, JPEG), Farbkonversionsalgorithmen und Transformationen.
  • Der Inspector XE ist ein Analysetool, das hilft, die Zuverlässigkeit von Applikationen zu testen und zu verbessern. Folgende Schlüsselfunktionen tragen dazu bei: Die dynamische und statische Speicherfehleranalyse (Memory Leak Analyse), sowie das Lokalisieren von nicht-deterministischen Fehlern paralleler Applikationen (Data Races und Deadlocks) während der Laufzeit.
  • Mit einem weiteren Analysetool, dem Intel VTune Amplifier XE, wird vor allem das Perfomance Profiling von seriellen und parallelen Programmen untersucht. Sowohl eine zeitliche Auflösung der Darstellung aller Threads aber auch eine statistische Darstellung und Anzeige von Funktionsaufrufen inklusive ihrer Stackinformation helfen dem Entwickler Problemen auf die Spur zu kommen. Die wichtigsten Funktionen umfassen: Hotspot-Analyse für CPU und System-on-Chip (SoC), Concurrencyanalyse (Nebenläufigkeitsuntersuchungen), Untersuchungen von Wait- und Lock-Ineffizienzen, Aufspüren von Loadimbalances bei gethreadeten Applikationen sowie Energieverbrauchsanalyse der eingesetzten CPU.

Weitere Debuggingfunktionen im Detail

Neben dem VTune Amplifier XE und dem Inspector XE gibt es weitere differenzierte System- und Applikations-Debugger-Funktionen, die insbesondere auf die Anforderungen der Embedded-Anwendungen zugeschnitten sind. So gibt es:

Bild 2: Intel JTAG-Debugger und JTAG-Hardwareprobe.

Bild 2: Intel JTAG-Debugger und JTAG-Hardwareprobe.Intel

  • den GNU-Project-Debugger für das schnelle Applikationsdebugging mit Instruktions-Trace und Data Race-Erkennung,
  • den Intel-JTAG-Debugger für das Systemdebugging von SoCs mit einem sehr geringen zeitlichen Overhead für das Eventtracing sowie das Debuggen von UEFI-Firmware, Bootloadern, Treibern und dem OS-Kernel,
  • ein User-Interface für den Entwickler, den Software Visible Event Nexus (SVEN), mit dem man den Applikationscode zum Beispiel für Testzwecke (auch im Feld) zum Auffinden von nicht-deterministischen Parallelisierungsfehlern instrumentieren kann. Im Gegensatz zu anderen Instrumentierungslösungen wird dabei der Programablauf nur mit minimalem zeitlichem Runtime-Overhead belastet.

Diverse JTAG-Hardwaregeräte wie Macraigor Systems, usb2Demon und die Intel-eigene ITP-XDP3 Probe, die über USB- oder TCP/IP-Schnittstellen angesprochen werden, vervollständigen die Entwicklungsumgebung (Bild 2).

Debugging von Firmware, Bootloader und OS Kernel mit Intel JTAG-Debugger

Jede Ebene des embedded Softwarestacks benötigt einen etwas anders gearteten Debugging-Ansatz. Für hardwarenahes Konfigurieren und Bootup unterstützt der Intel JTAG-Debugger ein Intel Eclipse RCP (Rich Client Platform) Plug-in-Interface, das folgende Funktionen anbietet:

  • Einen Bitfeld-Editor, der Peripheriefunktionen, Prozessorstatus und Softwarestus auf Bitebene auslesen und manipulieren kann.
  • Eine Visualisierung der Page-Table, die das Mapping des virtuellen Adressraums auf den physikalischen Adressraum anzeigt (Bild 3).
  • Zugriff auf die General-Descriptor-Table (GDT), die es erlaubt die Eigenschaften Programmausführbarkeit (Executability) und Schreibzugriff des Speichers zu untersuchen. Der Zugriff auf die Local Descriptor Table (LDT) ermöglicht es Speicherbereiche für spezielle Programme zu reservieren.
  • Betriebssystem-Speichermanagement und Speicherkonfiguration.
Bild 3: Memory Address Translation des JTAG-Debuggers von Intel.

Bild 3: Memory Address Translation des JTAG-Debuggers von Intel.Intel

Unter Umständen wollen Entwickler die Firmware verändern, um zum Beispiel die Boot-up-Zeit zu verkürzen oder nur die tatsächlich benötigten Peripheriegeräte eines Embedded-Systems anzuschalten. Dies gelingt mit UEFI-kompatiblen Firmwarelösungen wie etwa dem Intel Firmware Support Package oder dem Intel Bootloader-Development-Kit. Diese UEFI-Firmware kann sowohl mit dem Microsoft C/C++-Compiler oder dem mitgelieferten Intel C/C+- Compiler übersetzt werden. Sie gibt es aber nur für die Windows Host-Umgebung.

Gerätetreiber-Debugging

Die Funktionen von Gerätetreibern sind oft kritisch hinsichtlich ihres zeitlichen Ablaufs. Das notwendige Instrumentieren für Debugging-Zwecke kann die Treiberfunktion zu langsam machen. Intel System Studio geht dieses Problem mit einem eigenen OS- und Treiber-Modul an, das auf die Embedded-Zielhardware geladen wird und ohne Instrumentation auskommt.

Instruktionen Tracing – Rekonstruieren des Programmflusses

Bild 4: Programmfluss- und Instruktions-Tracing.

Bild 4: Programmfluss- und Instruktions-Tracing.Intel

Die Fähigkeit Fehler im Quellcode zurückzuverfolgen ist das Kernkonzept eines erfolgreichen Debuggens. Intel System Studio nutzt das sogenannte Befehlsinstruktions-Tracing. Dies ist eine Funktion, die in den Atom-Prozessoren hardwaremäßig verdrahtet ist. Eine Branch-Trace-Store-Einheit (BTS) führt Buch über die ausgeführten Branches eines Testlaufs, indem es die entsprechenden Daten in den Ringpuffer des Betriebssystems schreibt (Bild 4). Während der Testzeit wird also der tatsächliche Befehlsablauf aufgezeichnet, um dann später mögliche (logische, algorithmische) Fehlerquellen einzugrenzen. Dieses Werkzeug untersucht die letzten Befehlssprünge (Last Branch Records, LBR), disassembliert den Befehlscode und zeigt den tatsächlichen Programmablauf an. Auch hier ist der zeitliche Overhead minimal.

Analyse nicht-deterministischer Fehlerquellen

Der zeitliche Ablauf von verschiedenen Threads, die Daten und Nachrichten austauschen wird durch die Betriebssysteme gesteuert. Der Entwickler hat darauf kaum oder keinen Einfluss und es kann zu nicht-deterministischen Fehlern (zum Beispiel Data Races und Dead Locks) kommen.

Das Debugging dieser schwer auffindbaren Fehler ist äußerst schwierig. Dies ist nicht nur ein Problem beim Testen des Programms. Es wird erst recht zu einem Problem, wenn solch ein Bug im Feld auftritt, wenn also das Embedded Device bereits ausgeliefert ist. Zu diesem Zweck beinhaltet Intel System Studio ein Open Source Softwaredevelopmentkit (SDK) namens SVEN, das als JTAG-Lösung das Debuggen mit Hilfe von sogennnten Event Traces durchführt. Es werden Breakpoints verwendet, die die Programmausführung bei Auftauchen definierter Ereignisse unterbrechen. Danach wird der Status graphisch angezeigt. Bei SVEN wird ein Datenevent (Datenereignis) als eine kleine Instrumentierungsstruktur unter Nutzung definierter charakteristischer Daten wie Event-Identifikationsnummer, Zeitstempel und Eventtyp abgebildet.

Damit können zeitabhängig Speicherzellenänderungen und Datenaustausch während der Laufzeit verfolgt werden. Das gilt übrigens auch im Feldeinsatz, wo man dann den instrumentierten Code bei Bedarf für Log-Zwecke gezielt einschaltet, an einen Host übermittelt und dann dort auswertet.

Applikationsdebugging mit GNU Project Debugger (GDB)

Intel System Studio hat seinen eigenen GNU Project Debugger (GDB), der auch Data Races detektiert und Branch-Trace-Instruktionsverfolgung anbietet. GDB kommt mit Code-Binaries, die die Zielsysteme Yocto Project und Windriver Linux unterstützen.

Um GDB zu nutzen, muss der Standarddebugger der Linuxdistribution auf den System-Studio-eigenen GDB umgeschaltet werden. GDB kann mit dem Eclipse IDE zusammenarbeiten und unterstützt das Remote Debugging mittels eines mitgelieferten Stück Software, dem Remote Debug Agent. Dieses Vorgehen ist sinnvoll, wenn das Embedded-Zielsystem nur wenige Ressourcen (CPU und/oder Speicher) besitzt. Dann werden die Testdaten mit einem schlanken Remote Debug Agent auf dem Zielgerät eingesammelt und zum Host gesendet.

Das erweiterte Intel System Studio GDB kann ein Programm in Echtzeit unterbrechen. Es reagiert auf Sharing Events und Data Races und zeigt die Bereiche des gethreadeten Programms an, der für diese Probleme infrage kommt.

Die GDB-Erweiterung unterstützt auch Branch Tracing. Es ermöglicht dem Entwickler mithilfe des GDB, Probleme mit inkorrekten Branches zu identizieren, solange der Bug nicht zum Totalabsturz der Anwendung geführt hat. Es ist eine sinnvolle Funktion für Branchprobleme, die mit anderen Debuggern nicht gefunden werden.