gdb/ddd set Environment

Hallo.
Ich möchte mein Programm debuggen welches eine eigene lokale shared Lib verwendet mittels gdb/ddd.

Aber der gdb/ddd ignoriert die lokale Bibliothek und versucht immer auf die Bibliothek zu zugreifen, welche ihm durch übergeordnete Pfade bekannt ist.

Wenn ich meine Software in der Konsole starte, definiere ich vorher den LD_LIBRARY_PATH und dann kann ich mittels ldd sehen, dass er die richtige Lib benutzt.

Im gdb/ddd scheint dies alles nciht zu klappen. wenn ich

show environment LD_LIBRARY_PATH

schreibe, gibt er mir sogar aus, dass alle Pfade richtig gesetzt sind

LD_LIBRARY_PATH = /MIL/RSN/DEV/RTS/tmp/holger:/usr/local/lib:/oracle9/app/oracle/product/9.2.0/lib:/MIL/RSN/DEV/RTS/lib/Linux-glibc-GNU4-debug:/usr/lib/jvm/jre/lib/i386/:/usr/lib/jvm/jre/lib/i386/client:/MIL/RSN/DEV/RTS/3rd_party/Linux-glibc-GNU4-debug/tcl/lib:/MIL/RSN/DEV/RTS/3rd_party/Linux-glibc-GNU4-debug/ngs/lib:/MIL/RSN/DEV/RTS/lib/Linux-glibc-GNU4-debug/kwidget:/RTS/SCS/asws_scs/libs

unter /tmp/holger liegt die richtige so-Lib. Aber beim anstarten der Software will er die dort einfach nicht nehmen und beendet sich mit der Fehlermeldung:

/MIL/RSN/DEV/RTS/tmp/holger/utils_test: undefined symbol: _ZN8nTorpDyn12getTorpDynIFEv

auf deutsch, er findet die neue Methode nicht in der Lib, weil er auf die falsche Lib schaut.

HILFE!

mfg
Holger

Fellhuhn

Eine Möglichkeit:

lokal eine Kopie der Libraries in einem Ordner anlegen, beliebige überschreiben und dann in gdb mit

set solib-absolute-prefix ./pfad

Diesen Pfad angeben, dann sollte das auch funktionieren.

danke für die schnelle Nachricht.

aber nun wird es noch kurioser.

folgendes habe ich gemacht

(gdb) set solib-absolute-prefix /MIL/RSN/DEV/RTS/tmp/holger/

danach

(gdb) run
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: .dynamic section for "/MIL/RSN/DEV/RTS/tmp/holger/libsmoswa_utils.so" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/libdl.so.2: No such file or directory.
Error while mapping shared library sections:
/MIL/RSN/DEV/RTS/lib/Linux-glibc-GNU4-debug/libstdc++.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/libm.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/libgcc_s.so.1: No such file or directory.
Error while mapping shared library sections:
/lib/libc.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/ld-linux.so.2: No such file or directory.

nicht nur dass er hier andere libs nicht mehr findet, er sagt auch noch ganz unverfrohren, dass
"warning: .dynamic section for "/MIL/RSN/DEV/RTS/tmp/holger/libsmoswa_utils.so" is not at the expected address (wrong library or version mismatch?)"

dabei kann ich genau diese so in der Konsole beim Anstarten außerhalb vom ddd nutzen, weil sie zeitgleich erstellt wurde wie mein test-exe

was meintest du mit Files Kopieren? mein executable und meine so-lib liegen schon in einem extra tmp Verzeichnis und nciht im Runtime-Verzeichnis unseres Systems?

Diesen Tmp-Ordner habe ich bei solib-absolute-prefix angegeben

noch ein update.

ich habe mal testweise, ein kleines Beispielprogramm auf dem Entwicklungsrechner per gdb angestartet und dort konnte ich problemlos jede so heranziehen wie ich es wollte.

Im Zielsystem geht das nicht.

gibt es u.U. Linux Einstellungen die man anfassen muss damit man lokale shared Libs heranziehen kann zum debuggen?

Fellhuhn

1. gdb muss normal gestartet werden, das file darf erst am Ende bekannt gegeben werden (mit "file meine-exec")
2. ALLE libs müssen in den Unterordner und die entsprechende Ordner-Struktur nachbilden die sonst da wäre.

Oder aber man arbeitet normal mit set environment und auf einem bereinigten System wo die Bash-Login-Skripte nicht irgend was ruinieren.

ich hoffe ich habe dich richtig verstanden.

ich habe jetzt in meinem tmp-Ordner die Unterordner so angelegt wie die libs auch unter Home liegen.

dahinein habe ich meine so-Lib kopiert, entsprechend der lage im Home-ordner.

danach habe ich mein executable angestartet und

set solib-absolute-prefix ./

gemacht.

es hat leider nix geholfen

Fellhuhn

wenn deine libs vorher unter /usr/libs/horst/... lagen und du in /usr/holger/tmp/ arbeitest, muss es so aussehen:

/usr/holger/tmp/usr/libs/horst/...

Da müssen ALLE verwendeten libs liegen. Dann packst deine dazu, ebenfalls an die richtige Stelle (überschreibst also die alte).

Dann gdb starten.
(gdb) set solib-absolute-prefix /usr/holger/tmp/
(gdb) file deine-exe
(gdb) set args deine-args
(gdb) run

Sollte funktionieren.

meiner Meinung nach habe ich es genau so gemacht

na ich hab morgen nen Date mit unserem Systemadmin.
Der kann zaubern...mal sehen ob der eine Lösung hat.

Stand der Dinge:

Ich hab das gerade mit unserem Admin angeschaut. Nach langer Analyse hat er irgendwo (ich hab es ehrlich gesagt nicht verstanden), in den beschreibungen zum gdb gefunden, dass es so wie es ist erwünscht ist von den Entwicklern des gdb.

der gdb scheint irgendwie intern noch ein Programm aufzurufen, und diesen Programm kennt nicht die lokal konfigurierten Werte aus dem LD_LIBRARY_PATH.

Wie wir es lösen wollen, wissen wir noch nicht, da wird es demnächst eine Besprechung der Admins untereinander zu dem thema geben.

ABER was geht:

Ich kann die Software in der Console anstarten und mich remote draufhängen.

Na mal sehen wie sich das alles entwickelt hier.

Die Ursache:

Zitat aus info:/gdb/Environment

_Warning:_ On Unix systems, GDB runs your program using the shell indicated by your `SHELL' environment variable if it exists (or `/bin/sh' if not). If your `SHELL' variable names a shell that runs an initialization file--such as `.cshrc' for C-shell, or .bashrc' for BASH--any variables you set in that file affect your program. You may wish to move setting of environment variables to files that are only run when you sign on, such as.login' or `.profile'.

Das Problem bei mir:
Bei uns im RTS wird LD_LIBRARY_PATH in der .cshrc gesetz bzw. überschrieben!

Lösung
Jetzt werden bei uns zusätzlich die Pfade aus ${LD_LIBRARY_PATH_DEBUG} an den Anfang von LD_LIBRARY_PATH hinzugefügt, wenn LD_LIBRARY_PATH_DEBUG definiert ist.

Fellhuhn

Also quasi:

Fellhuhn schrieb:

Oder aber man arbeitet normal mit set environment und auf einem bereinigten System wo die Bash-Login-Skripte nicht irgend was ruinieren.