Valgrind Tobias Neumann Fachhochschule Aachen, Fachbereich Elektrotechnik und Informationstechnik, Eupener Strae 70, 52066 Aachen, Germany tobias.neumann@alumni.fh-aachen.de Zusammenfassung In dieser Arbeit wird das Valgrind DBI Framework für DBA Tools beschrieben. Dazu wird ein kurzer Überblick über die verschiedenen Analysemethoden von Programmen gegeben, und darüber wie DBA Tools Client Code Instrumentieren können. Auf den Aufbau von Valgrind wird eingegangen. Der Ablauf einer Analyse wird Schritt für Schritt erklärt. Es werden DBA Tools die mit Valgrind entwickelt wurden kurz Vorgestellt und Performancemessungen gezeigt. Keywords: Valgrind, Dynamic binary analysis (DBA), Dynamic binary instrumentation (DBI), DBI Framework, DBA Tools 1 Einführung und Hintergrund Analysetools erleichtern Programmierern die Arbeit. So können Debugger bei der Fehlersuche helfen, Profiler bei Performance Verbesserungen unterstützten oder Memorychecker bei beidem. 1.1 Analyse Methoden Die verschiedenen Analysetools können dabei in zwei verschiedene Kategorien eingeteilt werden [1]. Statische Analyse analysiert den Source- oder Maschinencode eines Programms ohne das Programm aus zu führen. [1] Dynamische Analyse analysiert ein Programm während es ausgeführt wird. Dabei muss das Analysetool das Client Programm um Analysecode Instrumentieren. Der Analysecode läuft dabei als Teil der normalen Ausführung des Programms, ohne dieses dabei zu stören. [1] Während bei der statischen Analyse das komplette Programm analysiert wird, wird bei einer dynamischen Analyse nur ein Programmpfad analysiert, dieser allerdings mit realen Werten. Analysetools lassen sich auch in zwei andere Kategorien einteilen.
2 Tobias Neumann Sourcecode Analyse analysiert den Sourcecode eines Programms. [1] Binärcode Analyse analysiert den Maschinencode eines Programms. [1] Durch diese beiden Aufteilungen entstehen die folgenden vier verschiedenen Analysemethoden. Statisch Dynamisch Sourcecode Statische Sourcecode Analyse Dynamische Sourcecode Analyse Binärcode Statische Binärcode Analyse Dynamische Binärcode Analyse Tabelle 1. vier Analysemodelle [1] Valgrind, das in dieser Arbeit beschrieben wird, ist für Dynamische Binärcode Analyse Tools oder auch Dynamic Binary Analysis (DBA) entwickelt. Wie oben bereits erwähnt, muss bei der Dynamischen Analyse der Programmcode des Clients mit dem Analysecode instrumentiert werden. 1.2 Code Instrumentierung für DBA Tools Für DBA Tools gibt es zwei Möglichkeiten Code in das Client Programm zu Instrumentieren. Statische Binäre Instrumentation instrumentiert den Maschinencode bevor das Programm ausgeführt wird. [1] Dynamische Binäre Instrumentation instrumentiert den Maschinencode während das Programm ausgeführt wird. [1] Valgrind nutzt Dynamische Binäre Instrumentation (DBI). 1.3 Code Darstellung Für DBI Frameworks gibt es zwei grundlegende Methoden den Code darzustellen und zu Instrumentieren [2]. Disassemble-and-resynthesise (D&R), wandelt jeden Maschinenbefehl in einen oder mehrere IR 1 -Befehle um. Dieser IR Code wird dann ebenfalls mit IR- Befehlen Instrumentiert und zurück in Maschinencode übersetzt. Dabei wird keiner der Ursprünglichen Befehle ausgeführt. [2] 1 intermediate representation [2]
Valgrind 3 Copy-and-annotate (C&A), stellt den Code in den ursprünglichen Befehlen dar. Diese Befehle werden durch Beschreibungen erweitert. [2] C&A Code eignet sich besonders für maschinennahe Analysen. Für ein DBI Framework entsteht weniger arbeit bei der Aufbereitung des Codes, dafür aber mehr bei der Instrumentierung [2]. D&R Code hingegen benötigt hohen Design aufwand. Durch seine Abstrakte Form bietet er nicht die Möglichkeit Clients maschinennah zu Analysieren. Da bei D&R der Maschinencode zuerst in einen Abstrakten IR übersetzt wird und am ende der instrumentierte IR wieder zurück in Maschinencode Kompiliert wird, ist die Laufzeit oft langsammer als bei C&A. Dies bringt allerdings den Vorteil Clientcode und Analysecode sehr eng zu verzahnen. [2] Desweiteren ist D&R kontrollierbarer. Ein Fehler bei der Übersetztung von Maschinencode zu IR führt häufig zu sichtbarem Fehlverhalten der Clients, während durch einen Fehler bei C&A ein korrekt laufender Client falsch analysiert wird [2]. In früheren Versionen von Valgrind wurde eine Mischung aus beidem benutzt, heute nutzt Valgrind nur noch D&R [2]. 1.4 Shadow Memory Shadow Memory ist der Speicher eines DBA Tools der Informationen über den Speicher des Clients hält. Der Analysecode des Tools aktualisiert den Shadow Memory als Reaktion auf Zugriffe auf den Client Speicher. Die Granularität von Shadow Memory kann dabei variieren, aber üblicherweise hat jedes Memory Wort einen Shadow Wert, der Informationen darüber enthält. [3] 1.5 Valgrind Valgrind wurde von Julian Seward als DBA Tool zur Speicherverwaltung entwickelt. Wärend der PhD thesis von Nicolas Nethercote in [1] (abgeschlossen 2004) wurde Valgrind zu einem Algemeinen DBI Framework umgebaut. Zuerst wurde Valgrind für x86/linux entwickelt [1]. Mitlerweile ist es auf die AMD64 2 /Linux [2], x86/darwin, AMD64/Darwin, ARM/Linux, ARM/Android [4] und weitere Platformen portiert worden. Durch diese Entwicklungen und Protierungen ist Valgrind heute ein bekanntes DBI Framework zur entwicklung von heavyweight DBA Tools. Der Ausdruck heavyweight beschreibt dabei DBA Tools die jeden Befehl Instrumentieren, Informationen zwischen Analysecode austauschen oder viele Informationen Sammeln [1]. DBA Tools werden als Plugins zum Valgrind Core hinzugefügt. Dabei gibt es folgende Aufteilung. Valgrind Core + Tool Plug-in = Valgrind Tool. [1] [2] 2 AMD64 ist eine andere Bezeichnung für x86-64
4 Tobias Neumann 2 Eigenschaften einer Valgrind Analyse In diesem Kapitel werden die genauen Abläufe und Vorgehensweisen während einer Analyse beschrieben. 2.1 Virtuelle Maschine Valgrind ist eine Virtuelle Maschine. Es selbst wird auf dem realen Rechner (Host) ausgeführt und führt das Client Programm auf einem Simulierten Rechner (Guest) aus [2] (siehe Kapitel 3). Der Core und Client befinden sich dabei in einem Prozess (siehe Kapitel 3.1). Die dadurch entstehenden Ressourcenkonflikte werden auf folgende weise gelöst. Partitionierung teilt die Ressource in unterschiedliche Bereiche auf. In Kapitel 3.1 wird dies für den Speicher gezeigt. Dieser wird zwischen Valgrind und Client geteilt und von Valgrind verwaltet [1] [2]. Zeitmultiplexing verteilt eine Ressource nach Zeitabschnitten. Valgrind nutzt dies für Register [1]. Die von einem Client genutzten Register (Guest Register) und die Shadow Register passen nicht gleichzeit in die realen Register (Host Register). Deswegen werden diese grundsätzlich im Speicher gehalten und nur wenn diese benutzt werden in Host Register geladen [1] [2]. Virtualisierung emuliert eine Ressource. Valgrind nutzt dieses für Plattformspezifische Befehle [2]. Sharing einer Ressource kann für Ressourcen auf die der Client und Core gleichzeitig zugreifen können genutzt werden wie z.b. die Prozess ID [1]. 2.2 Threads Würde Valgrind in verschiedenen Threads laufen, müsstens alle Speicherzugriffe gelockt werden. Gerade bei Tools die Shadow Memory nutzten würde dies zu extremen Performanceeinbusen führen, da sowohl der Client Zugriff auf den Speicher wie auch der Tool Zugriff gelockt werden müssen. [1] Um dennoch Multithreaded Client Code zu unterstützten, benutzt Valgrind eine eigene Implementierung des POSIX pthreads Modelles. Dies sorgt dafür das Threaded Client Code vom Core geschedult werden kann und in einem einzigen Kernel- Thread läuft (Abgesehen von den in Kapitel 2.3 und 2.4 gezeigten Sonderfällen). Dabei ist das komplette Scheduling unter Valgrinds Kontrolle. Dieses Vorgehen macht Thread-bezogene Events, wie z.b. die Erstellung und Terminierung von Threads und Mutex Sperrungen, für Valgrind sichtbar. [1] 2.3 System Calls System Calls müssen, da Valgrind nur Usercode Analysieren kann, unverändert ausgeführt werden. Damit System Calls richtig arbeiten, muss es für den Kernel so aussehen als wenn der Client normal läuft. Um das zu gewährleisten wird wenn der Client ein System Call ausführt folgende Schritte vollzogen. [1]
Valgrind 5 1. Der Tool Stack pointer wird gespeichert 2. Der Client State wird in die Host Register gespeichert, abgesehen vom Programm Counter 3. Der System Call wird ausgeführt 4. Der Client State wird zurück in den Speicher gesichert 5. Der Tool Stack pointer wird zurück gesichert 2.4 Signale Signale stellen für DBI Frameworks ein besonderes Problem dar. Wenn ein Programm ein Signal Handler erstellt, wird dem Kernel eine Callback Adresse übergeben, die zum Ausliefern des Signales benutzt werden muss. Diese Adresse darf ein Client nicht setzten, da der Kernel sonst beim senden eines Signales Client Code ohne die Kontrolle von Valgrind aufrufen würde. Deswegen werden Aufrufe zur Anmeldung von Signal Handlern vom Core abgefangen. Stattdessen merkt sich der Core die Callback Adresse und meldet einen eigenen Signal Handler an. Dieser Signal Handler des Cores ruft lediglich die Callback Adresse des Client, aber unter der Kontrolle von Valgrind auf. [1] Um asynchrone Signale zu Empfangen werden von Valgrind Proxy Threads bereit gestellt. Jeder Thread eines Clients hat dabei einen eigenen Proxy Thread. Diese warten auf den Empfang von asynchronen Signalen. Wenn ein asynchrones Signal von einem Proxy Thread empfangen wird, wird dieser vom Scheduler ausgeführt. Die Weiterreichung an den Client erfolgt dabei auf die gleiche weiße wie für synchrone Signale. [1] 2.5 Client Requestes Client requests sind Befehle die, wenn das Programm ohne Valgrind ausgeführt wird, no-ops sind, also die Semantik nicht verändern. Wenn das Programm mit Valgrind ausgeführt wird, werden diese Befehle vom Valgrind Core erkannt und verarbeitet, oder gegebenenfalls an das Tool weitergeleitet [1]. Dabei können Argumente übergeben werden oder ein return Wert empfangen. Client requests können in jeder Programmiersprache, die eingebetteten Assemblercode unterstützt, genutzt werden. Für C und C++ sind header-files mit fertigen MACROS zur verfügung gestellt. [1] 3 Ablauf einer Valgrind Analyse Bei der Analyse eines Programms (Client) mittels Valgrind, wird zuerst der Valgrind Core (Core) geladen. Anschließend läd der Core den Client in den gleichen Prozess (siehe Kapittel 3.1, Starten von Valgrind). Zur anschließenden Analyse nutzt Valgrind Dynamic Binary Instruction. Dabei wird der Maschinencode des Clients execution-driven in Blöcke aufgeteilt (siehe Kapitel 3.2, Basic Blocks). Diese werden dann Block für Block just-in-time recompeliert. [2]
6 Tobias Neumann Valgrind Tool 2 IR instructed IR 1 Valgrind Core 3 Machine code Machine code Abbildung 1. Ablauf Valgrind Der Ablauf dabei ist in Abbildung 1 gezeigt. Zuerst wird ein Block vom Core in einen RISC-artigen IR 3 Code recompeliert (bei 1, siehe Kapitel 3.4, Disassemblierung) und anschließend an das Tool weitergeleitet. Das Tool kann nun diesen IR Code analysieren und entsprechenden Analysecode zu dem IR Code hinzufügen (bei 2, siehe Kapitel 3.4, Instrumentierung). Anschließend wird der IR Code vom Valgrind Core zurück in Maschinencode übersetzt und ausgeführt (bei 3, siehe Kapitel 3.4, Rückumwandlung). [2] Der vom Tool hinzugefügte Analysecode wird dabei ebenfalls in IR dargestellt und zusammen mit dem Client Code vom Core zurück zu Maschinencode übersetzt. Da Valgrind DBI zur Analyse nutzt, müssen Programme die analysiert werden nicht vorbereitet werden. Dennoch kann die Analyse durch Debuging Informationen und ins Programm integrierte Client requests verbessert werden (siehe Kapitel 2.5, Client Requestes) [1]. 3.1 Starten von Valgrind Während der Entwicklung von Valgrind wurden verschiedene Methoden gewählt um Valgrind zu starten. In frühen Versionen wurde die LD PRELOAD 4 Umgebung genutzt um Valgrind in den Client Prozess zu laden, anschließend wurde die Ausführung übernommen. Durch dieses Vorgehen konnten mit Valgrind keine Programme die nur statisch gelinkt worden sind analysiert werden und die Ausführung konnte erst nachdem eine Dynamisch gelinkte Bibliothek genutzt worden ist übernommen werden. Desweiteren konnte Valgrind dadurch selbst 3 früher auch UCode genannt [1] 4 Mit LD PRELOAD kann unter Unix-artigen Betriebssystemen der Pfad für Dynamisch gelinkte Bibliotheken verändert werden [5]
Valgrind 7 keine Bibliotheken nutzten die ein Client verwendet. [1][2] Dieses Vorgehen wurde später durch den Valgrind loader (Loader) ersetzt. Der Loader läd dabei den Valgrind Core an eine hohe Adresse. Anschließend wird das Tool und der Client vom Core in den gleichen Prozess geladen. Dabei entsteht das folgende Speicherlayout [1]. 0xc0000000-0xffffffff. Der obere Bereich ist für das Betriebssystemen reserviert. 0xb0000000-0xbfffffff. Die nächsten 256MB werden für den Valgrind Core, Tool und deren Bibliotheken genutzt. 0x00000000-0xafffffff. Von den restlichen 2,75GB wird der untere Teil für den Client genutzt und der Rest für die Analyse des Tools. Diese Speicheraufteilung hat den Vorteil, dass der Core ab beginn der Ausführung die volle Kontrolle über den Client hat und diese nicht mehr über gelinkte Bibliotheken erreichen muss [1]. Allerdings entstehen dadurch große leere Speicherbereiche um die Komponenten an ihre Speicherplätze zu zwingen, was sich als unzuverlässig herausgestellt hat [2]. Deswegen wurde dieses Vorgehen zu einer dritten, aktuell eingesetzten Methode, leicht abgeändert. Jedes Tool hat den Valgrind Core (ca. 2,5MB) statisch gelinkt. Dadurch entsteht für ein Valgrind Tool nur ein Executable. Dieses Excecutable wird an die Adresse 0x38000000 geladen, welche beim Programmstart typischerweise frei ist. Ist dies nicht der Fall muss Valgrind mit einer anderen Adresse neu Kompiliert werden. Zum Schluss wird der Client vom Core geladen und Valgrind ist bereit mit der Analyse zu beginnen. [2] 3.2 Basic Blocks Bei der Analyse eines Clients wird der Maschinencode in Basic Blocks unterteilt. Diese Blöcke werden dann einzeln bevor sie ausgeführt werden von Valgrind analysiert. Ein Basic Block ist dabei eine Reihe aufeinanderfolgender Maschinencode-Befehle. Ein Basic Block beginnt bei dem Ziel eines Sprunges und endet wenn von ihm weggesprungen wird, z.b. durch jump, call oder return. [1] 3.3 IR Code Anfänglich hat Valgrind einen x86-spezifischen Assembler ähnlichen IR-Code genutzt. Mit Version 3.0.0 wurde dieser durch einen Architektur unabhängigen singel-static-assignment 5 (SSA) IR-Code ersetzt [2]. Jeder IR block beinhaltet dabei Statements. Dies sind Operationen mit Nebeneffekten, wie z.b. das Schreiben von Registern oder Speichers. Jedes Statement beinhaltet Expressions. Diese enthalten Werte, haben also keine Nebeneffekte. 5 Bei singel-static-assignment wird jeder Variable nur genau ein mal ein Wert zugewiesen [6]
8 Tobias Neumann Expressions sind z.b. Konstanten, gelesene Register oder Arithmetische Operationen. [2] Architektur spezifische Anweisungen werden dabei von Valgrind emuliert [2]. 3.4 Translations Translations sind die von Valgrind bereits Übersetzten, also instrumentierten, Maschinenbefehle von Basic Blocks. Diese werden in der Translation-table, einer Hashtable mit fester größe, gespeichert. Falls die Hashtable zu voll wird (ca. 80%) werden 1/8tel der Tabelle FIFO gelöscht. [1] [2] Desweiteren werden Einträge entfernt wenn der Ursprungs Basic Block durch selbst modifizierenden Code verändert wurde [2]. Eine Translation wird dabei in den folgenden fünf Schritten erzeugt. In [2] ist der 5. Schritt in vier einzelne Schritten aufgeteilt. Disassemblierung Bei Disassemblierung während einer Analyse werden die Maschinenbefehle in Basic Blocks aufgeteilt und Blockweise in tree-ir disassembliert. Dabei wird jeder Maschinenbefehl durch ein oder mehrere IR-Befehle ersetzt, so das eine wie in Abbildung 2 gezeigte, Baumartige Ersetzung entsteht. [2] MC 1 MC 2 MC 3 IR 1 IR 2 IR 3 IR 4 IR 5 IR 6 Abbildung 2. Maschinencode zu tree-ir Optimierung Der Optimierungsschritt ändert den tree-ir in flat-ir. Bei der Optimierung werden unter anderem redundante get- und put-methoden gelöscht, Instruktionen zusammengefügt und toter Code entfernt. [2] Durch diese Änderungen sind die IR-Befehle nicht mehr eine Maschinenbefehl zuzuordnen, so das keine Baumartige Struktur mehr existiert. Instrumentierung Die Instrumentierung erfolg im Tool. Dies kann den IR- Code willkürlich ändern und so den Analysecode in Form von IR-Befehlen hinzufügen. [2]
Valgrind 9 Optimierung 2 Nachdem das Tool den instrumentierten IR-Code zurück an den Core gibt, wird dieser ein zweites mal Optimiert. Dabei werden diesmal lediglich Instruktionen zusammengelegt und toter Code entfernt. Dies bietet Tools den Vorteil Analysecode ohne darüber nach zu denken zu dem IR-Code hinzu zu fügen. [2] Rückumwandlung Die Rückumwandlung von instrumentierten IR-Code zu Maschinencode erfolgt in mehreren Schritten. Zuerst wird der IR-Code in tree- IR-Code transformiert. Dieser wird in eine instruction list umgewandelt. Diese beinhaltet die aus dem tree-ir entstehenden Maschinenbefehle, allerdings noch mit virtuellen Registern. Anschließend werden die virtuellen Register durch Host Register ersetzt und zum Schluss wird dieser Code zurück in Maschinencode Kodiert. [2] 3.5 Ausführen von Translations Wenn ein Basic Block übersetzt wurde kann er ausgeführt werden. Nachdem er Ausgeführt wurde fällt der Controll Flow zurück zum Core. Der Dispatcher guckt in einem kleinen LRU Cache nach der nun kommenden Translation. Dieser Cache hat eine Trefferrate von ca. 98%. Wird er dennoch nicht fündig, wird der Scheduler aufgerufen der in der Translation-table nach der Translation sucht. Findet auch der Scheduler die Translation nicht, wird eine neue Translation erstellt. [2] In früheren Versionen wurden aufeinanderfolgende Translationen an einander gekettet [1]. Dies wird in der aktuellen Version nicht gemacht, da es noch nicht Implementiert ist. Durch die hohe Trefferrate und schnelle Implementierung des Dispatchers ist dies aber nicht wesentlich störend [2]. 3.6 Abschluss einer Analyse Wenn ein Client fertig ist und den Systemcall exit() aufruft, hört der Core auf zu analysieren und führt die letzten Anweisungen aus. Anschließend ruft er das Tool auf, damit dieses alle notwenidgen Abschlüsse durchführen kann. Zum Schluss ruft der Core den Systemcall exit() selbst auf, mit dem vom Client übergebenen Code. [1] 4 Tools Dieses Kapittel soll nur einen kurzen Überblick über mit der Valgrind Distribution mitgelieferten DBA Tools geben. Memcheck erkennt Speichermanagement Probleme. Es ist das meistverbreitete DBA Tool [2] und wurde zusammen mit Valgrind entwickelt. Bei einer Analyse mit Memcheck werden alle Speicherzugriffe überprüft. Dadurch kann es folgende Fehler erkennen. Zugriff auf nicht erlaubte Speicherbereiche
10 Tobias Neumann Benutztung von Uninitialisieren Variablen Memory Leeks Schlechte Freigabe von Heap Blöcken Die Übergabe von Überlappenden Speicherblöcken zu Funktionen wie memcpy() und ähnlichen Cachegrind ist ein Cach Profiler. Es Simuliert den Zugriff auf den I1 D1 und L2 Cache einer CPU und kann so die Cachemisses eines Programmes erkennen. Callgrind ist eine Erweiterung zu Cachegrind das zusätzlich noch Aufrufsgraphen zeigt. Massif ist ein Heap Profiler, der die Heap benutzung über die Zeit, und welche Teile des Programmes dafür verandwortlich sind, analysiert. Helgrind ist ein Thread debugger der Data Races erkennt. Es Sucht dafür nach Speicherbereichen die von mehreren Threads geändert werden, dabei aber nicht geschützt sind. DRD ist ebenfalls ein Thread debugger, der allerdings keine Locking Fehler erkennt, dafür aber weniger Speicher zur Analyse als Helgrind benötigt. Nulgrind ist ein Tool das keinen Analysecode hinzufügt und lediglich zu Testzwecken da sind. Abgesehen von diesen Tool sind mit Valgrind noch viele weitere DBA Tools entwickelt worden und teilweise auch frei im Internet erhältlich. [4] 5 Valgrind Tool Performance In [2] wurden Performance Messungen mit SPEC CPU2000 Benchmarks durchgeführt. Diese wurden auf einer 32-Bit Maschine mit einer 2,4GHz Intel Core 2 Duo CPU mit 4MB L2 Cache und 1GB RAM mit SUSE LINUX 10.2, Kernel 2.6.18.2, durchgeführt. Es wurden vier Tools dargestellt mit dehnen Zeitmessungen durchgeführt worden sind. 1. Nulgrind, ein Tool das keinen Analysecode hinzufügt 2. ICntI, ein Instruktions Zähler, welcher Inline-Code nutzt um einen Counter nach jeder Instruktion zu erhöhen 3. ICntC, ein Tool wie ICntI mit dem Unterschied das kein Inline-Code sondern der Aufruf zu einer C-Funktion zum erhöhen des Zählers genommen wurde 4. Memcheck, ein heavyweight Tool, das zu jedem Client-Wert im Speicher einen Shadow-Wert mit Informationen darüber speichert. Tabelle 2 zeigt den Slowdown Faktor dieser Tools. [2] Der Slowdown Faktor von Nullgrind ist, dafür das keine Analyse durchgeführt wird, sehr hoch. Dies liegt an der Client-Code darstellung mittels D&R, welche sich für leichtgewichtige Tools nicht eignet. Durch die Zeitunterschiede zwischen ICntI und ICntC erkennt man den Vorteil von Inline Analysecode im vergleich zu dem Aufrufen von C Funktionen. Bei Memcheck liegt der mittlere Soldown Faktor bei 22,1. Dies ist nicht extrem höher als bei den anderen getestetens Tools obwohl Memcheck eine deutlich aufwändigere Analyse durchführt. [2]
Valgrind 11 Programm Nat. (s) Nulg. ICntI ICntC Memc. bzip2 192,7 3,5 7,2 10,5 16,1 crafty 92,4 6,9 12,3 22,5 36,0 eon 408,5 7,5 11,8 21,0 51,4 gap 131,3 4,0 9,1 13,5 25,5 gcc 90,0 5,3 9,0 14,1 39,0 gzip 212,1 3,2 5,9 9,0 14,7 mcf 87,0 2,0 3,5 5,4 7,0 parser 218,9 3,6 7,0 10,4 17,8 perlbmk 179,6 4,8 9,6 14,6 27,1 twolf 262,5 3,1 6,5 10,7 16,0 vortex 86,7 6,5 11,4 17,8 38,7 vpr 149,4 4,1 7,7 11,3 16,4 ammp 345,2 3,4 6,5 9,1 32,7 applu 583,0 5,2 14,1 28,1 19,7 apsi 469,0 3,4 8,2 12,5 16,4 art 100,4 4,7 9,4 13,7 24,0 equake 118,2 3,8 8,4 12,4 17,1 facerec 280,9 4,7 8,2 12,2 17,4 fma3d 284,7 4,1 9,4 16,2 26,0 lucas 183,5 3,7 7,1 10,8 24,8 mesa 148,9 5,9 10,3 15,9 57,9 mgrid 809,1 3,5 9,8 14,4 16,9 sixtrack 355,7 5,6 13,4 18,3 20,2 swim 388,2 3,2 11,9 15,3 10,7 wupwise 192,1 7,4 11,8 17,3 26,7 geo. mean 4,3 8,8 13,5 22,1 Tabelle 2. Performance von vier Valgrind Tools mit SPEC CPU2000 [2] Literatur 1. Nethercote, N.: Dynamic Binary Analysis and Instrumentation or Building Tools is Easy. PhD thesis, University of Cambridge, United Kingdom (2004) 2. Nethercote, N., Seward J.: Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation. San Diego, California, USA (2007) 3. Nethercote, N., Seward J.: How to Shadow Every Byte of Memory Used by a Program. San Diego, California, USA (2007) 4. Valgrind webpage, http://valgrind.org/ 5. Wikipedia, Dynamic linker, http://en.wikipedia.org/wiki/dynamic_linker 6. Wikipedia, Static single assignment form, http://en.wikipedia.org/wiki/ Static_single_assignment_form