Stammtisch: Nachlese vom 24. November 2011

Assemblervortrag

Am Donnerstag, dem 24. November 2011 waren Mitglieder des Maschinenraums Weimar, insbesondere Eick, beim Hackspace Jena zu Gast und haben uns eine Einführung in Assembler gegeben. Dabei kam es wie immer zu interessanten Gesprächen und einem regen Wissensaustausch. Hier noch einige Ergänzungen zum Vortrag:

• Für die Intel‐Architektur gibt es zwei konkurrierende Assembler‐Schreibweisen: Intel und AT&T. Die Vorgabe bei gcc ist die AT&T-Syntax, welche aber von einigen nicht als so schön empfunden wird. Man kann aber mit der Option -masm=intel auf Intel‐Syntax umstellen.

  Wenn man mit Assembler beginnt und erst einmal ein Gefühl dafür bekommen will, wie Konstrukte zum Beispiel in C in Assembler umgesetzt werden, kann man den gcc direkt Assembler‐Code ausgeben lassen.

  gcc -S example.c

  In der Datei example.S steht dann der Assembler‐Code. Mit der oben erwähnten Option -masm=intel kann man diesen dann auch in Intel‐Syntax erhalten.

  Dieser Code enthält etwas mehr Informationen, u.a. Sprungmarken, die man in der Disablembler‐Ausgabe von gdb nicht bekommt, wodurch der Code teilweise besser zu lesen ist. Man kann dann einfach in seinem C‐Code Änderungen vornehmen und beobachten, was im Assembler‐Code passiert; für Linux‐Nutzer ist natürlich diff das Mittel der Wahl.

  Wichtig sei auch hier noch mal die Erwähnung, dass man keine Optimierung wie -O2 verwenden sollte. Oder doch mal ausprobieren und sehen, was dann passiert. ;-)

• Um Programme zu disassemblieren, kann man auch mit objdump arbeiten und muss nicht gdb verwenden.

  objdump -d -M intel /bin/true

  Hier gibt es auch wieder die zwei Syntaxvarianten wie beim gcc oben schon erwähnt.

• Interessant beim Debuggen des Assemblers ist im gdb die Anweisung display. Diese zeigt bei jedem Anhalten eine Ausgabe. Somit kann man sich zum Beispiel immer die Anweisung ausgeben lassen, die auf ihre Ausführung wartet: display /i $eip (bei PowerPC ist es $pc). Wenn man dann durch das Programm mit stepi (bzw. nur Return) läuft, sieht man immer, was kommt.
• Eine andere Hilfe hatte Jörg schon beim Vortrag genannt: Das Text‐User‐Interface. Entweder mit der gdb‐Anweisung tui oder gdb mit der Option -tui aufrufen. Vorsicht, da sind die Tastenbelegungen anders.
• Wer tief in die Welt der Programmausführung abtauchen will, dem sei der Artikel A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux empfohlen.
• Am Rande gab es die Frage, ob das Windows‐COM‐Dateiformat und das a.out‐Dateiformat gleich sind, sprich man könnte einfache com‐Dateien auch auf Linux ausführen. Aufgrund der Seiten in der englischen Wikipedia, ist dem wahrscheinlich nicht so.
• Von Konrad kam die Frage, was Debug‐Symbole sind. Die Antwort, dass es eine Liste mit Zuordnungen von Assembler‐Befehlen zu den Befehlen in der Hochsprache sind, ist nicht vollständig. Debug‐Symbole enthalten noch mehr Informationen, aber auf die Schnelle konnte ich keine Informationen dazu finden.
• Noch eine nette Eigenschaft von gdb sei erwähnt: Man kann den Zustand eines Programms zum Laufzeit manipulieren. Wenn man also beim Debuggen feststellt, dass eine Berechnung ein falsches Ergebnis liefert, kann man es an der geeigneten Stelle mit set var $VAR=42 korrigieren und die Programmausführung fortsetzen.

Die Unterlagen zum Vortrag liegen auf dem M18-Server.