Ich versuche, eine Anwendung zu debuggen, die auf einem Windows-Host für ein Linux-Ziel kompiliert ist.
Das Problem:
Da die Erstkompilierung in Windows erfolgt, haben die gespeicherten Quelldateipfade in der Binärdatei die Form C:\Users\foo\project\... . Auf dem Linux-Ziel habe ich die Quelldateien unter \home\foo\project\.... gestellt. Standardmäßig findet gdb die Quelldatei wegen des unterschiedlichen Pfades nicht.
Was ich bisher versucht habe:
Verwenden Sie den Befehl "directory" in gdb, um einen genauen Pfad für die .c-Quelldatei im Linux-Zielsystem anzugeben, auf dem die Anwendung debuggt wird. Dies funktioniert, aber leider gibt es buchstäblich Hunderte von Dateien, so dass diese Lösung unrealistisch ist.
Verwenden Sie den Befehl set substitute-path C:\Users\foo\project /home/foo/project , damit gdb alle Präfixe ersetzt. Beachten Sie, dass \ notwendig erscheint, damit show substitute-path die richtige Zeichenfolge registriert. Dies funktioniert leider nicht. Meine Vermutung ist, dass der Befehl "substitute-path" keine MS-DOS-Stilpfade behandelt.
Es wurde versucht, die Debug-Informationen in eine separate .debug-Datei zu trennen (siehe Wie erzeuge ich das GCC-Debug-Symbol außerhalb des Build-Ziels? ) und benutze dann debugedit, um die Pfade mit dem Befehl debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug zu ändern. Leider funktioniert das auch nicht. debugedit scheint gut zu funktionieren, wenn der vorhandene Pfad vollständig UNIX / Linux-ähnlich ist, aber nicht mit ms-dos-Stilpfaden zu funktionieren scheint.
Ich habe mich in stackoverflow umgesehen und während es ähnliche Themen gibt, kann ich nichts finden, was mir helfen würde. Würde mich über Vorschläge / Hilfe freuen. Mir ist klar, dass Cross-Compiling von Windows ein Umweg ist, den ich aber im Moment nicht vermeiden kann.
Danke
Obwohl es eine ziemlich alte Frage ist, ist mir das gleiche Problem begegnet. Ich schaffte es, es zu lösen, aber mit sed auf binäre ausführbare Datei ... (ja, ein 'bisschen' hack-ish, aber nicht anders gefunden). Mit sed habe ich es geschafft, Symbolpfade direkt in der ausführbaren Datei zu ersetzen, der Trick ist, dass die Länge des neuen Pfades gleich der alten sein sollte.
Achten Sie darauf, dass der neue Pfad die gleiche Länge hat, sonst bricht die ausführbare Datei ab.
Ich habe auch das gleiche Problem. Ihre Option 1 ist nicht so schlecht, wie Sie denken, weil Sie Skripte erstellen können, die alle 'Verzeichnis' -Befehle mit etwas wie diesem Python-Code erstellen:
%Vor%Der Nachteil ist, dass, wenn Sie zwei Quelldateien mit demselben Namen in verschiedenen Verzeichnissen haben, ich glaube nicht, dass gcc die richtige auswählen kann. Das beunruhigt mich, aber in meiner besonderen Situation denke ich, dass ich in Sicherheit bin.
Für Option 2 (von der ich vermute, dass sie die Alias-Bedingung von # 1 aus beheben würde), glaube ich, dass die Substitutionen nicht mit einem "file separator" enden, so dass sie nicht angewendet werden:
Um unerwartete Substitutionsergebnisse zu vermeiden, wird eine Regel nur angewendet, wenn der from-Teil des Verzeichnisnamens an einem Verzeichnistrennzeichen endet. Zum Beispiel wird eine Regel, die / usr / source in / mnt / cross ersetzt, auf /usr/source/foo-1.0 angewendet, nicht aber auf /usr/sourceware/foo-2.0. Und da die Substitution nur am Anfang des Verzeichnisnamens angewendet wird, wird diese Regel auch nicht auf /root/usr/source/baz.c angewendet. "(Von Ссылка )
Ich habe noch nichts wie # 3 versucht, und ich habe auch etwas wie @dragn suggestion erwogen, aber in meiner Situation sind die Pfade nicht einmal annähernd gleich lang, also wird das ein Problem sein.
Ich denke, ich bin mit # 1 und einem Skript fest, aber wenn jemand andere Vorschläge hat, bin ich interessiert Optionen: -)
Tags und Links windows linux cross-compiling gdb