Seg fault beim Ausführen von arm-elf-gcc kompiliertem Code

Question

Mit MacPorts habe ich gerade arm-elf-gcc auf meinen MacBook Pro installiert. Dies hat einwandfrei funktioniert und alles scheint gut zu laufen.

Nach dem Kompilieren eines einfachen "Hello World" Testprogramms in C und C++ und dem Versuch, es auf dem Zielboard (einem ARM9 basierten Board mit Debian Linux) auszuführen, treten sofort Segmentation faults auf.

Ich bin etwas ratlos, wie ich das debuggen soll, da auf dem Zielboard nur begrenzte Tools verfügbar sind und kein gdb vorhanden ist. Ich habe erfolgreich anderen Code mit einem Linux-basierten Cross-Compiler erstellt und ausgeführt, also sollte es funktionieren.

Ideen?

Nach dem Vorschlag habe ich gdbserver erstellt und ausgeführt, ich erhalte Folgendes in gdb auf dem Host:

Programm hat ein Signal SIGSEGV erhalten, Segmentation fault. 0x00000000 in ?? ()

Ich dachte es könnte ein Problem mit den Standard-C-Bibliotheken sein, also habe ich alle Aufrufe entfernt und habe nur ein leeres Hauptprogramm, das 0 zurückgibt. Es ist mit -Wall -g hello-arm.cpp -static kompiliert. Zum Test habe ich die gleiche Quelle mit einem Linux-basierten Cross-Compiler kompiliert und sie läuft und beendet sich fehlerfrei. Der einzige Unterschied, den ich erkennen kann, ist, dass die mit Linux kompilierte Version mehr als doppelt so groß ist und der Unterschied in der Ausgabe des Befehls file:

arm-elf-gcc: ELF 32-Bit LSB ausführbare Datei, ARM, Version 1, statisch gelinkt, nicht gestrippt

arm-*-linux: ELF 32-Bit LSB ausführbare Datei, ARM, Version 1, statisch gelinkt, für GNU/Linux 2.4.18, nicht gestrippt

Answer 1

Die übliche Methode zur Fehlersuche in dieser Situation besteht darin, gdbserver auf der Zielplatine auszuführen und eine Verbindung dazu (über Ethernet) mit gdb auf einem Hostcomputer herzustellen.

Alternativ könnten Sie versuchen, den Assemblercode in einem auf dem Mac kompilierten "Hello World"-Programm und einem (funktionierenden) Linux-kompilierten Programm zu vergleichen, um herauszufinden, was anders ist.

Answer 2

Nachdem ich ein paar Tage lang herumgegraben habe, fange ich langsam an, ein wenig mehr über eingebettete Compiler zu verstehen. Ich war mir nicht ganz sicher über den Unterschied zwischen arm-elf-gcc, installiert über MacPorts, und dem arm-unknown-linux-Toolchain, den ich auf meinem Linux-Rechner installiert hatte. Ich bin gerade auf ein PDF mit dem Titel "Eine Einführung in den GNU-Compiler" gestoßen, das den folgenden Absatz enthält:

Wichtig: Die Verwendung des GNU-Compilers zur Erstellung Ihres ausführbaren Codes ist nicht ganz dasselbe wie die Verwendung des GNU-Linkers, arm-elf-ld, selbst. Der Grund dafür ist, dass der GNU-Compiler automatisch eine Reihe von Standard-Systembibliotheken in Ihren ausführbaren Code einbindet. Diese Bibliotheken ermöglichen es Ihrem Programm, mit einem Betriebssystem zu interagieren, die Standard-C-Bibliotheksfunktionen zu nutzen, bestimmte Sprachfunktionen und Operationen (wie etwa Division) zu verwenden usw. Wenn Sie genau sehen möchten, welche Bibliotheken in den ausführbaren Code eingebunden werden, sollten Sie dem Compiler das verbose-Flag -v übergeben.

Dies hat wichtige Auswirkungen auf eingebettete Systeme! Solche Systeme haben normalerweise kein Betriebssystem. Das bedeutet, dass das Einbinden der Systembibliotheken fast immer bedeutungslos ist: Wenn beispielsweise kein Betriebssystem vorhanden ist, macht es zum Beispiel keinen Sinn, die Standard-printf-Funktion aufzurufen.

Also werde ich später an meinem Entwicklungsrechner die eingebundenen Bibliotheken des Linux-Builds bestimmen und sie dem arm-elf-gcc-Build hinzufügen.

Ich werde dies aktualisieren, wenn ich mehr Informationen habe, aber ich möchte nur meine Erkenntnisse dokumentieren, falls jemand anderes diese Probleme hat.