Übersicht
Stichwortsuche
History
Versionen
Kategorien
Alle Artikel
SuSE Linux: Versionen ab 6.0
Sie wollen ein selbstentwickeltes Programm mit dem gdb debuggen, bekommen aber immer einen Fehler der folgenden Art:
(gdb) s strcmp (p1=0x4001fdc1 "fopen", p2=0x804834d "printf") at ../sysdeps/generic/strcmp.c:30 ../sysdeps/generic/strcmp.c:30: No such file or directory.
Sie benutzen den Step Befehl des gdb (s
) und wechseln damit
in eine Systemfunktion. Der gdb gerät in den dynamischen Linker und Sie
kommen dort nicht mehr heraus. Bei der libc5 tratt
dieses Problem nicht auf, da dafür keine Debuginformationen
vorlagen. Der gdb ignorierte in dem Fall die Step
Anweisung und führt
ein Next
aus. Im Gegensatz zur libc5 wird die glibc2 mit
Debuginformationen ausgeliefert, da dieses häufig die Fehlersuche vereinfacht.
Grundsätzlich sollte der Next
Befehl des gdb (n
)
benutzt werden. Und nur bei Funktionen, in die wirklich gewechselt werden soll, ist der
Step
Befehl zu benutzen. Im Normalfall ist der Fehler selten
in der C Library zu finden, sondern im eigenen Programmcode.
Teilweise werden aber Systemaufrufe in Macros versteckt. Das Problem hierbei
ist, daß die Funktion häufig noch nicht "lazy-text-resolved" aufgelöst wurde
und der gdb dadurch aus den Tritt
gerät. Eine Lösung ist das Setzen der Variable LD_BIND_NOW
vor dem Debuggen.
Bei der bash führen Sie bitte folgendes aus:
tux@erde > LD_BIND_NOW=1; export LD_BIND_NOW tux@erde > gdbbzw. für die tcsh:
tux@erde > setenv LD_BIND_NOW 1 tux@erde > gdb
Stichwörter: GDB, GLIBC2, DEBUGGEN
Kategorien:
Entwicklungswerkzeuge
Übersicht
Stichwortsuche
History
Versionen
Kategorien
Alle Artikel