Artikelformat

ARM beim Debuggen, reich an Erfahrung

Heute habe ich richtig was gelernt. Die Aufgabe war eigentlich ganz einfach, ich habe ein kleines ARM basiertes Board (Target) und einen Entwicklungsrechner (Host) der via LAN und serieller Konsole mit dem Target verbandelt ist. Das Target-Filesystem liegt zudem als NFS-Mount auf dem Host.

Ziel der Übung waren zwei Dinge. Zum einen wollte ich ein einfaches C-Programm (Hello World mit einer Schleife) auf dem Host via Cross-Compiler so übersetzen dass es auf dem ARM-System läuft. Und dann das ganze natürlich auch debuggen.

Zum Übersetzen gibt es bei der Code-Sourcery eine Toolchain die frei und gratis ist, letztlich sind das der gcc und die binutils in einer Anpassung um damit Code für die ARM-Architektur zu erzeugen. Das ganze ist natürlich Kommandozeilenbasiert und nicht für eine schöne graphische IDE wie Eclipse gemacht.

Dem kann man allerdings abhelfen wenn man die Eclipse-Einstellungen ein wenig erweitert. Ich habe mal zwei Build-Variablen definiert nämlich CROSS_COMPILE=’arm-linux-none-gnueabi-‚ und ARCH=’arm‘. Die Settings für die Build-Utilities, (gcc, ld und as) werden so angepasst, dass der Compiler dann mit ${CROSS_COMPILE}${COMMAND} aufgerufen wird. Dazu muss die Toolchain natürlich im Pfad (PATH-Variable setzen) vorhanden sein.

Mit diesen Einstellung klappt es dann schon, ein Programm für die ARM-Plattform zu übersetzen. Auf die Zielmaschine übertragen ist einfach, ich muss es nur in den NFS-Share schieben der ja auf meinem Host liegt.

Die eigentliche Denksportaufgabe war das Debuggen, denn die Target-Maschine kennt nur den gdb-server. Also muss der Host-Rechner dahin kontaktieren und dann debuggen. Das hat aber erst mal gar nicht funktioniert. Egal was ich probiert habe, immer nippelte das Target mit einem Segfault ab. Irgendwann kam dann via Google die Erleuchtung: Für eine solche Debug-Situation (Target = ARM, Host = Intel) muss der gdb auf dem Host auch für die ARM-Plattform übersetzt werden. Also habe ich mal den genommen der bei der Code-Sourcery mitgeliefert wird und der hat schon mal ganz gut funktioniert. Noch besser war allerdings dann, diesen Debugger in die Debug-Einstellungen bei Eclipse einzutragen, denn dann kann man vollständig aus der Eclipse-IDE heraus zum Zielmaschine verbinden und die Debug-Session machen.

Autor: Rainer

Diplom-Informatiker, Baujahr 1961, Vater von 2 Kindern, Hundehalter, Sportschütze und Vereinsvorstand, Hobbymusiker (mit zweifelhaftem Erfolg), politisch interessiert, Leseratte, Freizeit-Philosoph und letztlich Blogger.

4 Kommentare

  1. Ich habe eine Frage.
    Ich habe versucht dies nachzuvollziehen, aber bei mir funktioniert es leider nicht.
    Vielleicht könntest du mir einen Tip geben.

    Ich habe mit Eclipse CDT und Sourcery_G++_Lite für mein ARM board eine exe erstellt. Diese kann ich auch auf meinem Board ausführen und sie funktioniert.
    Jetzt habe ich aber mit dem Remote debuggen ein Problem.
    Ist mein Ansatz richtig:

    Mein Board verfügt über Ethernet und ich habe für mein Board einen gdbserver über opkg heruntergeladen und installiert.
    Ich habe mein Testprogramm auf das Target (mein Board) kopiert. /home/myTest

    Ich starte den Server über:
    > gdbserver 192.168.0.140:2345 /home/myTest
    — er lauscht

    In Eclipse habe ich auf meinem Host eine neue Debug Configuration angelegt:
    Debug Configurations / C C++ Remote Application / New

    Beim Debugger habe ich den gdb von Sourcery_G++_Lite eingestellt
    /home/georg/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-gdb

    Bei der Connection habe ich mein Target:
    192.168.0.51 Port 2345 eingestellt.

    Eclipse verbinden, bricht jedoch sofort mit dieser Fehlermeldung ab:

    Error in final launch sequence
    Failed to execute MI command:
    -target-select remote 192.168.0.51:2345
    Error message from debugger back end:
    Malformed packet(b) (missing colon): ore:0;
    Packet: ‚T050b:00000000;0d:d0ddb6be;0f:f0070040;thread:fde;core:0;‘

    Malformed packet(b) (missing colon): ore:0;
    Packet: ‚T050b:00000000;0d:d0ddb6be;0f:f0070040;thread:fde;core:0;‘

    Hast du vielleicht einen Tip was ich falsch gemacht habe? Mir kommt es komisch vor, dass ich das Programm auf dem Target händisch starten muss.

    Danke im Voraus.

    Georg

    • Hallo Georg,
      ich hab es nochmal hier nachgeseehen, meine Debug-Konfiguration sieht so aus wei bei Dir.
      Im E2E-Forum von Texas Instruments gibt es aber einen Thread der Dir vielleicht weiterhilft:
      Linux Aware Debugging CCSv5 GDB server GDB host issue. Sieht so aus als müssten die Versionen von gdbserver und gdb zusammenpassen. Aus welchem Zweig von Angström hast Du Deinen gdbserver bezogen?

      Gruß
      Rainer

  2. Super danke du hast mir den richtigen Weg aufgezeigt!!
    Als ich eine andere Version des gdbserver auf meinem Board verwendet habe hat es geklappt.

    Danke noch einmal.
    Georg