Debuggen von optimiertem Code

Eine besonders interessante Eigenschaft des CXdb ist die Möglichkeit, optimierten Code debuggen zu können. Dabei sind zwei Hauptprobleme zu überwinden, die beim Optimieren entstehen:

1. Eine Source-Zeile kann mehrfach oder gar nicht im Object-Code dargestellt sein oder die Reihenfolge der Zeilen kann sich ändern.
2. Variablen im Source sind u.U. wegoptimiert worden und tauchen im Object-Code nicht mehr oder nur als Register auf; umgekehrt können neue Größen als Hilfsvariable eingeführt worden sein.

Die Grundlage zur Lösung des ersten Problems ist der Übergang von Source-Zeilen zu allgemeinen Source-Units. Insbesondere kleinere Einheiten (Expressions) oder größere Einheiten (Blocks, Routinen) sind oft besser im Object-Code wiederzufinden. Außerdem bietet das Markieren der aktuellen Source-Unit die Möglichkeit, beim schrittweisen Durchlaufen die geänderte Reihenfolge oder ein mehrfaches Auftauchen im Source-Fenster entsprechend anzuzeigen. Das zweite Problem wird dadurch gelöst, daß für jede Variable auch ein Gültigkeitsbereich im Object-Code - der eben von dem im Source-Code abweichen kann - und ein Ort (Speicherplatz oder Register) mitgeführt wird. Außerdem kennt der CXdb auch die vom Optimierer erzeugten Variablen (''synthetische Variable'') und ihren Bezug zu Source-Variablen. Damit kann er - meistens jedenfalls - aus den synthetischen die Source-Variablen, die im Object-Code nicht mehr vorkommen, rekonstruieren. Trotz dieser Hilfen ist das Debuggen von optimierten Programmen mühsam und sollte nur in besonderen Fällen benutzt werden, z.B. wenn man den Optimierer als Fehlerursache im Verdacht hat - das kommt seltener vor als man denkt! - oder wenn man bereits länger laufende Prozesse debuggen will. I.f. sollen einige typische Schwierigkeiten, die beim Debuggen von skalar optimiertem und vektorisiertem Code auftreten, am Beispiel linalg vorgestellt werden. Das Debuggen parallelisierter Programme wird im Abschnitt 4.4.2 behandelt.