"Illegal instruction" bei der Kompilierung von Qt 4.7

Question

"Illegal instruction" bei der Kompilierung von Qt 4.7

8

Ich kämpfe seit mehr als einer Woche mit diesem Problem und kann immer noch keine Lösung finden ...

Ich versuche Qt 4.7 Embedded-Open-Source-Version für ein ARM-Gerät Cross-kompilieren. Der Build-Prozess selbst schließt ohne Probleme ab, aber die generierten Binärdateien scheinen Anweisungen zu enthalten, die der Prozessor nicht versteht.

Build host ist Debian 5 (Etch) auf i386 (läuft auf einem virtuellen PC)
Das Gerät ist ein Trimble Nomad-Handheld mit einem ARM-Prozessor ( vollständige cpuinfo und Kernel-Konfiguration )
Ich benutze die originale Build-Toolchain, die für das Gerät hergestellt wurde und die bisher gut funktionierte (sogar könnte man Gnash erstellen) erfolgreich) - siehe Compilereinstellungen und Version
Ich verwende eine benutzerdefinierte qmake.conf basierend auf linux-arm-gnueabi-g++ und angepasst, um die richtige Toolchain zu verwenden - siehe Quellcode hier
Ich habe eine partielle Verbesserung durch Hinzufügen von -msoft-float -D__GCC_FLOAT_NOT_NEEDED zu den Compiler-Flags erhalten, bekomme aber trotzdem < Illegal instruction -Fehler in einige Situationen (aber das war zumindest eine große Verbesserung)
Die Binaries selbst funktionieren grundsätzlich, aber in bestimmten Situationen stürzt das Programm mit dem Fehler "Illegal instruction" ab. Ich glaube, dass dies während bestimmter Gleitkommaoperationen geschieht, während man Grafiken macht.
Das Hinzufügen von -mcpu=xscale , -march=armv4 , -O0 , -march=armv4 , -mtune=arm920t (nicht alle gleichzeitig) hat in keiner Weise geholfen.
Das Erstellen von Qt mit dem --debug -Flag scheint alle Probleme zu lösen , aber das Hinzufügen des -O2 -Flags führt sie wieder ein. Seltsamerweise hilft die Einstellung -O0 ohne --debug nicht .
Die Ausgabe von compilete configure und make ist hier zu sehen. Es gibt viele Alignment-Warnungen, aber es wird gesagt, dass sie falsche Warnungen des Compilers sind .
Es muss einige Änderungen in Qt 4.7.2 gegeben haben, da frühere Versionen (4.7.1, 4.7.0) gut funktionieren .

configure Einstellungen:

%Vor%

strace vor dem Absturz:

%Vor%

gdb backtrace des Absturzes (Ich vermisse Debug-Symbole, da das Kompilieren mit Debug-Informationen das Problem behebt):

%Vor%

Beachten Sie, dass das Gerät mit Qtopia 4.3 vorinstalliert ist und der Hersteller das Problem mit meinem Build auch nicht erklären kann.

Aktualisieren

Mit Hilfe von Igor Skochinsky konnte ich die genaue Assembleranweisung finden, die den SIGILL verursacht. Aus irgendeinem Grund funktioniert die Anweisung für 47 mal , bevor der Fehler verursacht wird. Siehe gdb output unten (beachten Sie, dass ich ARM Assembler überhaupt nicht kenne):

%Vor%

Irgendwelche Vorschläge, was ich als nächstes versuchen könnte?

qt cross-platform arm cross-compiling

Udo G 11.04.2011, 12:40

quelle

2 Antworten

Tags und Links qt cross-platform arm cross-compiling

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Sie können Aufgaben in Redmine schnell (per Drag & Drop) neu anordnen?

score 4 · Answer 1

Die geteilte Disassemblierung ist ziemlich interessant.

%Vor%

Der Code prüft auf Bit 9 in fpscr und, falls gesetzt, versucht er, die Register f2-f7 zu speichern. Was sind diese? Ich habe sie noch nie in den letzten Prozessoren gesehen, aber ich denke, dass es sich um FPA-Register ("Floating Point Accelerator" -Register) handelt, die in einigen alten Kernen implementiert sind und für Soft-FPs verwendet wurden, bevor VFP erschien.

Also, hier ist, was ich denke passiert:

Die libc auf Ihrem Gerät wurde kompiliert mit FPA-Unterstützung, wahrscheinlich von Fehler.
In FPA-Prozessoren Bit 9 gemeint "FPA aktiviert" oder so ähnlich
In der Debug-Version von Qt das Bit 9 von FPSCR (DZE = Division by Zero Ausnahme aktivieren Bit) ist nicht eingestellt, so dass sie nicht versuchen, FPA zu speichern Register. Es wird jedoch eingestellt die Release-Version.

Ich sehe hier zwei Optionen:

Rebuild libc ohne FPA-Unterstützung
Finde, wo DZE in der Version ver setzt wird (nicht sicher, wie das geht)

Aktualisieren : Ich habe mich geirrt. Die Demontage von gdb hat mich verwirrt. Ich habe die Quelle von setjmp.S, hier ist der relevante Teil:

%Vor%

Es versucht also, WMMXt-Register zu speichern, nicht FPA. Allerdings gibt es hier einen Fehler. Es verwendet r2, um fpscr vorübergehend zu speichern, aber , das den zuvor geladenen hwcap-Wert in a3 überschreibt (a3 ist das APCS-Name für r2). Vielleicht wollte der Autor a2, nicht r2, oder vielleicht wurden die beiden Teile von verschiedenen Leuten gemacht. In beiden Fällen ändert die Release-Version von Qt irgendwie FPSCR (was höchstwahrscheinlich vom Kernel emuliert wird) und der Code, der iwmmxt regs speichert, wird ausgelöst.

Trotzdem ist das nicht die ganze Geschichte. Die , die Sie eingefügt , behaupten, dass die CPU iWMMXt unterstützt, also bin ich mir nicht sicher, warum diese Anweisungen Probleme bereiten würden. Vielleicht ist der gemeldete PC-Wert irgendwie falsch. Ich denke, du solltest versuchen, einen Haltepunkt auf __sigsetjmp zu setzen und durch Anweisungen (Schritt) hindurchzugehen, um zu sehen, wo genau es abstürzt.

score 0 · Answer 2

Hallo, ich hatte vor ein paar Tagen ein ähnliches Problem ... Aber ich habe Qt Creator 5.7 auf meinem Slackware Linux im VMware-Player (nicht ARM-Gerät) ausgeführt.
Nach erfolgreicher Installation konnte ich Qt Creator nicht starten. Ich habe versucht, Qt Creator mit dem folgenden Terminal-Befehl /opt/Qt5.7.0/Tools/QtCreator/bin/qtcreator auszuführen, und es gab mir einen Fehler Illegal instruction .
Nach ein paar Stunden mit Google habe ich versucht, Qt Creator mit diesen Terminalbefehlen /opt/Qt5.7.0/Tools/QtCreator/bin/qtcreator -noload Welcome zu starten, und das funktionierte für mich.

Hoffe, das hilft jemandem. Entschuldigung für eine späte Antwort.