Wie kommst du normalerweise um dieses Problem herum? Stellen Sie sich vor, ein Thread stürzt innerhalb von libc-Code (der eine gemeinsam genutzte Systembibliothek ist) auf Computer1 ab und erzeugt dann einen Arbeitsspeicherabzug. Aber der Computer2, auf dem dieser Arbeitsspeicherabzug analysiert wird, könnte eine andere Version von libc haben.
Also:
Wie wichtig ist es, dieselbe gemeinsame Bibliothek auf dem entfernten Computer zu haben? Wird die gdb Stacktrace korrekt rekonstruieren, ohne genau die gleiche Version von libc auf Conputer2 zu haben?
Wie wichtig ist es, korrekte Debug-Symbole für libc zu haben? Wird die gdb Stacktrace korrekt rekonstruieren, ohne exakt dieselben Debug-Symbole auf dem Computer2 zu haben?
Und was ist der "richtige" Weg, um dieses Debug-Symbol-Mismatch-Problem für gemeinsam genutzte Systembibliotheken zu vermeiden? Für mich scheint es, dass es keine einzige Lösung gibt, die dieses Problem elegant löst. Vielleicht kann jemand seine Erfahrung teilen?
Kommt drauf an. Auf einigen Prozessoren, z. B. x86_64 , sind korrekte Abwicklungsdeskriptoren für GDB erforderlich den Stapel richtig abwickeln. Auf einer solchen Maschine wird das Analysieren von Coredump mit nicht übereinstimmender libc wahrscheinlich vollständigen Müll produzieren.
Sie benötigen keine Debug-Symbole für libc, um den Stack-Trace zu erhalten. Sie würden keine Datei- und Zeilennummern ohne Debug-Symbole erhalten, aber Sie sollten korrekte Funktionsnamen erhalten (außer wenn Inlining stattgefunden hat).
Die Prämisse Ihrer Frage ist falsch - Debug-Symbole haben damit nichts zu tun. Der "richtige" Weg, um Coredump auf C2 zu analysieren, wenn dieser Coredump auf C1 erzeugt wurde, ist eine Kopie der C1-Bibliotheken (in /tmp/C1/lib/... ) und direkte GDB, um diese Kopie anstelle der C2 installiert libc mit zu verwenden
(gdb) set solib-absolute-prefix /tmp/C1
Befehl.
Hinweis : Über die Einstellung muss gesetzt sein, bevor Sie den Core in GDB laden. Dies:
%Vor%funktioniert nicht (Core wird gelesen, bevor die Einstellung wirksam wird).
Hier ist der richtige Weg:
%Vor%(Ich habe versucht, einen Verweis darauf im Internet zu finden, aber nicht).
Was sind Abwicklungsdeskriptoren?
Abwicklungsdeskriptoren sind erforderlich, wenn Code ohne Rahmenzeiger kompiliert wird (Standard für x86_64 im optimierten Modus). Ein solcher Code speichert nicht das% rbp-Register, weshalb GDB angewiesen werden muss, vom aktuellen Frame zum Aufrufer-Frame "zurückzutreten" (dieser Prozess wird auch als Stack-Unwinding bezeichnet).
>Warum ist die libc.so von C1 nicht im Kern enthalten?
Die Kerndatei enthält normalerweise nur den Inhalt beschreibbarer Segmente des Programmadressraums. Die schreibgeschützten Segmente (in denen sich ausführbarer Code und Abwicklungsdeskriptoren befinden) sind normalerweise nicht erforderlich - Sie können sie einfach direkt von libc.so auf der Festplatte lesen.
Das funktioniert jedoch nicht, wenn Sie den C1-Kern auf C2 analysieren!
Einige (aber nicht alle) Betriebssysteme erlauben es, "Full Coredumps" zu konfigurieren, bei denen das Betriebssystem auch schreibgeschützte Mappings ablegt, damit Sie den Core auf jedem Rechner analysieren können.
Tags und Links shared-libraries gdb remote-debugging postmortem-debugging