2008-09-17 11 views
24

Ich habe eine Core-Datei, die auf einem Remote-System erstellt wurde, auf das ich keinen direkten Zugriff habe. Ich habe auch lokale Kopien der Bibliotheksdateien vom Remote-System und die ausführbare Datei für das abstürzende Programm.Wie stelle ich einem Verzeichnis den Bibliothekspfad vor, wenn ich eine Core-Datei in gdb unter Linux lade

Ich möchte diesen Core Dump in Gdb analysieren.

Zum Beispiel:

gdb path/to/executable path/to/corefile 

Meine Bibliotheken sind im aktuellen Verzeichnis.

In der Vergangenheit habe ich gesehen, Debugger implementieren dies mit der Option "-p." oder "-p/=."; Also meine Frage ist:

Wie kann ich angeben, dass Bibliotheken zuerst aus Pfaden relativ zu meinem aktuellen Verzeichnis geladen werden, wenn eine Corefile in Gdb analysiert?

Antwort

39

starten gdb ohne die ausführbare Datei oder Kerndatei angeben, geben Sie die folgenden Befehle ein:

set solib-absolute-prefix ./usr 
file path/to/executable 
core-file path/to/corefile 

Sie müssen aus dem Zielsystem stellen Sie sicher, genau den Bibliothekspfad spiegeln. Obiges ist für das Debuggen von Zielen gedacht, die nicht mit Ihrem Host übereinstimmen. Aus diesem Grund ist es wichtig, Ihre Root-Dateisystemstruktur zu replizieren, die Ihre Bibliotheken enthält.

Wenn Sie remote einen Server debuggen, die die gleiche Architektur und Linux/glibc Version als Gastgeber, dann können Sie tun, wie fd vorgeschlagen:

set solib-search-path <path> 

Wenn Sie versuchen, einige der Bibliotheken außer Kraft zu setzen , aber nicht alle, dann können Sie die Verzeichnisstruktur der Zielbibliothek in einen temporären Bereich kopieren und die oben beschriebene solib-absolute-prefix Lösung verwenden.

+0

Ich habe den Pfad ein bisschen falsch, so möchten Sie vielleicht Ihre Antwort zu aktualisieren. Ich werde diese Antwort auffrischen, weil sie teilweise meinen Anforderungen entspricht, aber ich sollte klarer sagen, dass ich einen Ort dem Bibliothekspfad voranstellen möchte, anstatt ihn zu ersetzen (mein Nachteil für das Wort "override"). –

+0

Danke, das hat mir wirklich geholfen! –

+0

In meinem Fall befanden sich die ausführbare Datei und ihre Bibliotheken in einer NFS-gemounteten Struktur und der Host, von dem ich debuggen wollte, war der NFS-Server, also legte ich einen Symlink in die Struktur, so dass solib-absolute-prefix nfs-share-tree war die genaue Lösung. Ich hoffe, das hilft zukünftigen Generationen. –

3

ich diesen Auszug auf developer.apple.com gefunden

set solib-search-path path 

Wenn diese Variable gesetzt ist, Pfad ist eine Doppelpunkt getrennte Liste von Verzeichnissen Suche nach gemeinsam genutzten Bibliotheken. solib-search-path' is used after solib-absolute-prefix 'schlägt fehl Suchen Sie die Bibliothek, oder wenn der Pfad zu die Bibliothek ist relativ statt absolut. Wenn Sie solib-search-path' instead of solib-absolute-prefix 'verwenden möchten, stellen Sie sicher, set solib-absolute-prefix' zu einem nicht vorhandenen Verzeichnis zu verhindern GDB von Host-Bibliotheken zu finden.

EDIT:

Ich glaube nicht, dass die oben genannte Einstellung unter Verwendung der Verzeichnisse prepends ich hinzu, aber es scheint sie anhängen, so Dateien von meinem aktuellen System fehlen in den Pfaden abgeholt Ich fügte hinzu. Ich schätze das Setzen des Solib-Absoluter-Präfixes auf etwas Falsches und das Hinzufügen von Verzeichnissen im Solib-Suchpfad in der von mir benötigten Reihenfolge könnte eine vollständige Lösung sein.

4

Ich bin mir nicht sicher, ob das überhaupt möglich ist, aber ich bin kein Experte.

Allerdings kann ich die Linux dynamische Linker kommentieren. Der folgende sollte den Pfad aller aufgelösten freigegebenen Bibliotheken und der nicht aufgelösten Bibliotheken drucken.

ldd path/to/executable 

Wir müssen wissen, wie Ihre gemeinsam genutzten Bibliotheken mit Ihrer ausführbaren Datei verknüpft waren. Um dies zu tun, verwenden Sie den folgenden Befehl ein:

readelf -d path/to/executable | grep RPATH 
  • Sollte der Befehl Druck nichts, wird der dynamische Linker Standard Standorte verwenden und die Umgebungsvariable LD_LIBRARY_PATH auf die gemeinsam genutzten Bibliotheken.

  • Wenn der Befehl einige Zeilen ausgibt, ignoriert der dynamische Linker LD_LIBRARY_PATH und verwendet stattdessen die fest codierten rpaths.

    Wenn die aufgelisteten rpaths absolut sind, ist die einzige Lösung, die ich kenne, das Kopieren (oder Symlink) Ihrer Bibliotheken zu den aufgelisteten Speicherorten.

    Wenn die aufgelisteten rpaths relativ sind, enthalten sie ein $ ORIGIN, das zur Laufzeit durch den Pfad der ausführbaren Datei ersetzt wird. Verschieben Sie entweder die ausführbare Datei oder die entsprechenden Bibliotheken.

Für weitere Informationen, können Sie beginnen mit:

man ld.so 
+0

Danke, das sind alles nützliche Informationen. –

+0

sehr nützliche Informationen. nicht verwandt mit gdb, aber sehr verwandt mit meinem Fall der Suche nach ld-Pfaden –

0

Eine wichtige Anmerkung:

, wenn Sie eine Kreuzkompilierung tun und versuchen, mit gdb zu debuggen, dann nach Sie haben
file ECECUTABLE_NAME getan, wenn Sie etw sehen. wie:

Using host libthread_db library "/lib/libthread_db.so.1" 

dann überprüfen Sie, ob Sie libthread_db für Ihr Zielsystem haben. Ich habe viele ähnliche Probleme im Internet gefunden. Solch ein Problem kann nicht einfach mit "set solib-" gelöst werden, Sie müssen libthread_db auch mit Ihrem Cross-Compiler erstellen.

2

Sie können auch LD_PRELOAD für jede der Bibliotheken oder LD_LIBRARY_PATH auf das aktuelle Verzeichnis beim Aufruf von gdb setzen. Dies führt nur zu Problemen, wenn gdb selbst versucht, eine der Bibliotheken zu verwenden, die Sie vorab laden.

+0

Command LD_LIBRARY_PATH = "." gdb executableName.bin hat gut funktioniert. Vielen Dank. – user2431763