Wie man gdbserver für Remote-Debugging unter Linux verwendet

Wenn Sie in C oder C++ programmieren Linux und du hast gdbserver noch nie benutzt.Sie verpassen eines der nützlichsten Werkzeuge zum Remote-Debuggen von Prozessen, sei es auf einem Server, einem eingebetteten System oder sogar in einer virtuellen Maschine oder WSL. Gdbserver ist alles andere als etwas „Magisches“ oder nur Experten vorbehalten, sondern einfach ein kleines Programm, das mit gdb kommuniziert und die Ausführung des Zielprozesses steuert.

Die Grundidee ist ganz einfach.: auf dem Rechner, auf dem die zu debuggende Binärdatei ausgeführt wird (der Ziel) Sie starten gdbserver; auf Ihrem Arbeitsrechner (dem GastgeberSie starten gdb oder WinDbg mit Unterstützung für das gdb-Protokoll. Beide stellen die Verbindung über TCP oder eine serielle Schnittstelle her. Von dort aus können Sie Haltepunkte setzen, Variablen untersuchen, den Stack anzeigen oder die Ausführung Schritt für Schritt verfolgen, als ob das Programm auf Ihrem eigenen Rechner laufen würde.

Was ist gdbserver und wann ist seine Verwendung sinnvoll?

gdbserver ist ein Remote-Debugging-„Agent“ für GNU gdb.Seine Funktion ist sehr spezifisch: Es läuft auf dem Rechner, auf dem das zu analysierende Programm läuft, steuert diesen Prozess (oder diese Prozesse) und kommuniziert über eine Remote-Verbindung mit einem gdb-Client, der sich auf einem anderen Rechner (oder auf demselben) befindet.

Im täglichen Gebrauch wird gdbserver in zwei typischen Szenarien eingesetzt.Debugging von Software, die in eingebetteten Umgebungen (Routern, Boards mit abgespecktem Linux, Geräten) läuft IoTetc.) und debuggen Prozesse auf entfernten Linux-Rechnern, wo es nicht praktikabel oder schlichtweg nicht möglich ist, ein "fettes" gdb mit allen Bibliotheken und Symbolen zu haben.

In der Praxis übernimmt gdbserver Aufgaben wie beispielsweise Prozessregister und Speicher lesen und beschreiben, die Ausführung steuern (fortsetzen, pausieren, schrittweise durchlaufen), Haltepunkte verwalten und all diese Daten mithilfe des GDB-Remote-Protokolls an gdb senden. Diese Vorgehensweise ähnelt stark der von Tools wie OpenOCD, die als Brücke zwischen gdb und einem Prozess fungieren. Hardware extern, mit dem Unterschied, dass gdbserver auf demselben System läuft, auf dem auch die Binärdatei ausgeführt wird.

Wenn Sie aus folgenden Umgebungen kommen Windows Es ist auch interessant zu wissen Debugger wie WinDbg können mit einem gdbserver unter Linux kommunizieren, sodass Sie Benutzerprozesse unter Linux von WinDbg aus debuggen können, indem Sie die Remote-Debugging-Unterstützung über das gdb-Protokoll nutzen, das Microsoft in den neueren Versionen integriert hat.

Grundvoraussetzungen für das Debuggen mit gdb und gdbserver

Bevor Sie mit dem Remote-Debugging beginnen, müssen Sie die Host/Ziel-Beziehung verstehen.. Die Ziel Es handelt sich um den Rechner, auf dem das zu debuggende Programm ausgeführt wird und auf dem gdbserver ausgeführt wird; der Gastgeber Dies ist der Rechner, von dem aus Sie gdb (oder WinDbg) ausführen und auf dem sich der Quellcode und, vorzugsweise, die Debugging-Symbole befinden.

Der wichtigste Ausgangspunkt ist die Kompilierung der Binärdatei mit Symbolen.In GCC oder g++ wird dies mit dem Flag erreicht. -gund es ist in der Regel ratsam, auch Optimierungen zu deaktivieren (zum Beispiel mit -O0Dadurch kann der Debugger Variablen, Makros und die Codestruktur genauer anzeigen. Für bestimmte Makros können Sie höhere Debugging-Stufen verwenden, wie zum Beispiel -g3.

Auf dem Host-System benötigen Sie eine kompatible Version von gdb. mit der Zielarchitektur. Um ein eingebettetes System mit MIPS-, ARM- oder anderer Architektur zu debuggen, müssen Sie gdb der entsprechenden Cross-Toolchain verwenden (zum Beispiel). arm-none-eabi-gdb o gdb-multiarch) und, falls erforderlich, die Architektur und die Byte-Reihenfolge konfigurieren mit Befehle als set arch y set endian.

Bezüglich der Verbindung unterstützt gdbserver zwei HaupttypenEine serielle Verbindung (sehr üblich bei eingebetteter Hardware, über UART) und TCP/IP, was am praktischsten ist, wenn sich das Ziel im selben Netzwerk befindet oder ein über das Netzwerk erreichbarer Linux-Rechner ist. In beiden Fällen wird der Befehl von gdb aus verwendet. target remote um eine Verbindung zum von gdbserver bereitgestellten Endpunkt herzustellen.

Möglichkeiten zum Starten von gdbserver: Einzelprozess- und Mehrprozessmodus

gdbserver kann auf zwei Hauptarten funktionieren Wenn wir von Benutzermodus-Debugging sprechen: entweder direkt einem einzelnen Prozess zugeordnet oder als "Prozessserver", der das Auflisten und Anhängen an verschiedene Systemprozesse ermöglicht.

Im Einzelprozessmodus Sie starten gdbserver und geben dabei Host:Port und das auszuführende Programm an. In einem einfachen Beispiel auf einem Linux-Desktop-Rechner könnte dies etwa so aussehen:

Befehl: gdbserver localhost:3333 foo

Mit diesem Befehl startet gdbserver die Binärdatei. foo und er lauscht weiterhin an Port 3333Solange keine Verbindung zu einem entfernten gdb-Server hergestellt wird, bleibt das Programm angehalten; sobald gdb eine Verbindung herstellt, … target remote localhost:3333Der Prozess wird nun vom Entzerrer kontrolliert.

Im Mehrprozessmodus (Prozessserver) wird die Option verwendet. --multiIn diesem Fall startet gdbserver kein Programm direkt, sondern wartet lediglich auf eingehende Verbindungen und überlässt es dem Client (gdb oder WinDbg), zu steuern, welcher Prozess erstellt oder an welchen er sich anhängen soll:

Befehl: gdbserver --multi localhost:1234

Bei der Arbeit mit WinDbg unter Linux ist dieser Multimodus besonders interessant.Da man mit WinDbg selbst Prozesse auf dem Remote-System auflisten, PID, Benutzer und Befehlszeile anzeigen und sich an den gewünschten Prozess anhängen kann, ähnlich wie beim Prozessserver. dbgsrv.exe in Windows.

Remote-Debugging mit gdbserver und gdb Schritt für Schritt

Um das Ganze greifbarer zu machen, betrachten wir ein sehr typisches Beispiel.: Debuggen einer einfachen Anwendung auf demselben Rechner (Host und Ziel stimmen überein) mithilfe von gdbserver, um das Remote-Szenario zu simulieren.

Zuerst schreibt und kompiliert man ein kleines Programm.Zum Beispiel eine alberne Schleife, die einen Zähler ausgibt:

Befehl: gcc -g foo.c -o foo

Der Schlüssel hierbei ist die Flagge. -gDadurch werden dem Binärfile die notwendigen Debugging-Informationen hinzugefügt, sodass gdb Codezeilen, Variablennamen, Typen usw. anzeigen kann. In einer „echten“ Cross-Compiling-Umgebung würden Sie diese Kompilierung mit der Cross-Toolchain durchführen und anschließend sowohl das Binärfile als auch seine Abhängigkeiten auf das Zielsystem kopieren.

Der nächste Schritt besteht darin, gdbserver auf dem Zielsystem zu starten.Wenn Host und Zielrechner derselbe Rechner sind, dann:

Befehl: gdbserver localhost:3333 foo

Sie werden eine ähnliche Meldung sehen wie: „Prozess foo erstellt; PID = XXXX; Lauscht auf Port 3333“. Dies bedeutet, dass gdbserver den Prozess erstellt hat und auf die Verbindung von gdb wartet. Falls Sie ein System verwenden, für das erweiterte Berechtigungen erforderlich sind (z. B. zum Anhängen an Systemprozesse), müssen Sie den Befehl möglicherweise mit folgenden Berechtigungen ausführen: sudoEs ist jedoch immer ratsam, bei der Erteilung von Genehmigungen vorsichtig zu sein. Wurzel zum Entschwefelungsgerät.

Auf dem Host starten Sie gdb und geben die lokale ausführbare Datei an. (dasselbe Programm, das auf dem Zielsystem läuft, oder eine identische Kopie mit Symbolen):

Befehl: gdb foo

Sobald Sie sich in gdb befinden, stellen Sie die Remote-Verbindung her mit:

Befehl: target remote localhost:3333

An diesem Punkt lädt gdb die Symbole aus der lokalen Binärdatei.Es synchronisiert sich mit gdbserver und übernimmt die Kontrolle über den Prozess, der aktuell unter gdbserver läuft. Von da an verläuft der Ablauf wie gewohnt: Befehle wie break um Wendepunkte festzulegen continue, step, next, print Variablen untersuchen, backtrace um die Batterie usw. zu sehen.

Verbindung zu laufenden Prozessen mit gdbserver herstellen

Man möchte das Programm nicht immer von Grund auf neu starten.Oftmals ist man daran interessiert, sich einem bereits laufenden Prozess anzuschließen (zum Beispiel einem httpd ein Routerein Systemdienst oder ein Produktionsdienst).

Üblicherweise verwendet man die Option --attach von gdbserverSie übergeben den Port, an dem der Server lauschen soll, und die Prozess-ID (PID) des Zielprozesses. Auf einem Router, auf dem Sie beispielsweise einen für seine Architektur kompilierten gdbserver installiert haben, könnten Sie Folgendes tun:

Befehl: gdbserver localhost:3333 --attach <pid_de_httpd>

Auf der Hostseite verwenden Sie eine Version von gdb, die die Architektur des Routers unterstützt.zum beispiel gdb-multiarchArchitektur und Byte-Reihenfolge im Voraus konfigurieren:

Befehl: set arch mips
set endian big

Anschließend geben Sie die lokale Datei an, die die Symbole enthält. der entfernten Binärdatei (zum Beispiel file httpd) und, falls erforderlich, teilen Sie gdb mit, wo die Binärdatei tatsächlich auf dem Zielsystem ausgeführt wird. set remote exec-file /usr/bin/httpdSchließlich stellen Sie, genau wie zuvor, die Verbindung her mit:

Befehl: target remote 192.168.0.1:3333

Sobald angebrachtSie können Haltepunkte für bestimmte Funktionen setzen (zum Beispiel break checkFirmware), die Ausführung fortsetzen und den normalen Programmablauf (z. B. das Hochladen der Firmware über die Weboberfläche) den Haltepunkt auslösen lassen.

Verwendung von gdbserver mit WinDbg unter Linux

In den letzten Jahren hat Microsoft die Unterstützung für das Debuggen von Linux-Prozessen in WinDbg erweitert. Die Funktionalität nutzt gdbserver als Backend. Sie ist für Szenarien gedacht, in denen Sie unter Windows arbeiten, der Code aber unter Linux (einschließlich WSL) ausgeführt wird.

Um einen bestimmten Linux-Prozess mit WinDbg mithilfe von gdbserver zu debuggenDer Ablauf wäre in etwa so: Zuerst lokalisiert man den Zielprozess auf dem Linux-Rechner mit einem Befehl wie ps -A (zum Beispiel ein python3 Wenn gdbserver bereits läuft), starten Sie ihn dann auf dem Zielsystem:

Befehl: gdbserver localhost:1234 python3

Wenn die Umgebung es erfordert, müssen Sie möglicherweise verwenden sudo gdbserver ...unter Beachtung der gleichen Sicherheitsvorkehrungen wie immer. Sobald gdbserver anzeigt, dass es „auf Port 1234 lauscht“, gehen Sie in WinDbg zu „Datei / Verbindung zum Remote-Debugger herstellen“ und geben Sie eine Verbindungszeichenfolge des folgenden Typs an:

Befehl: gdb:server=localhost,port=1234

WinDbg verwendet einen kleinen gdb-Protokoll-"Treiber", um mit gdbserver zu kommunizieren. und sobald die Verbindung hergestellt ist, bleibt sie an diesem Punkt stehen. Starten des Prozesses. Von dort aus können Sie dessen Stack-Fenster, Module, Speicher, Haltepunkte sowie Befehle wie die folgenden verwenden: k um die Batterie zu sehen oder lm um Module aufzulisten (beachten Sie dabei, dass einige Befehle das PE-Format und nicht das ELF-Format erwarten, sodass sie in bestimmten Fällen möglicherweise seltsame Daten anzeigen).

gdbserver und WinDbg-Prozessserver

Neben dem Einzelprozessfall kann WinDbg auch eine Verbindung zu einem gdbserver herstellen, der als Prozessserver fungiert. um ähnlich wie bei Remote-Windows-Prozessen zu funktionieren. In diesem Modus wird gdbserver gestartet mit --multi und ohne zugehörigen Prozess:

Befehl: sudo gdbserver --multi localhost:1234

Wählen Sie in WinDbg „Datei / Verbindung zum Prozessserver herstellen“. und Sie verwenden die Verbindungszeichenfolge wieder. gdb:server=localhost,port=1234Wenn die Verbindung aktiv ist, können Sie die verfügbaren Linux-Prozesse auflisten und sich an den gewünschten Prozess anhängen oder sogar einen neuen Prozess starten.

Ein subtiles Detail muss beachtet werden.WinDbg unterscheidet zwischen „Prozessserver“ und „Einzelzielserver“, je nachdem, ob gdbserver beim Verbindungsaufbau bereits an einen Prozess angehängt ist. Wenn Sie gdbserver an einen Prozess angehängt gelassen, WinDbg geschlossen und anschließend versucht haben, die Verbindung wiederherzustellen, wird er möglicherweise nicht als Prozessserver erkannt, und Sie müssen gdbserver gegebenenfalls neu starten.

Um eine Prozessserversitzung zu beendenNormalerweise genügt es, in der Konsole, in der gdbserver läuft, Strg+D zu drücken und das Debuggen mit WinDbg zu beenden. In seltenen Fällen, etwa bei Synchronisierungsproblemen, kann es jedoch erforderlich sein, den Debugger vollständig zu schließen und gdbserver neu zu starten.

Symbol- und Quellcodeverwaltung beim Remote-Debugging

Einer der Schlüssel zu komfortablem Remote-Debugging ist die korrekte Auflösung der Symbole und Schriftarten.Ohne Symbole wird das Navigieren im Stack oder das Setzen von Haltepunkten für bestimmte Funktionen zur Qual.

In klassischen gdb + gdbserver-Szenarien ist es ideal, eine Kopie der ausführbaren Datei mit Symbolen auf dem Host zu speichern. (ungestrippt) und dem Quellcodebaum. gdb benötigt nicht, dass die entfernte Binärdatei die Symbole enthält; es genügt, wenn die lokale Datei, die Sie laden, mit file Die Remote-Executable auf Offset-Ebene abgleichen.

In der Welt des WinDbg- und Linux-Debuggings sind auch Dienste wie DebugInfoD entstanden.die Symbole und Schriftarten über HTTP bereitstellen. WinDbg kann spezielle Pfade des Typs verwenden. DebugInfoD*https://debuginfod.elfutils.org beide .sympath wie in .srcpath zum Herunterladen von DWARF-Symbolen und Linux-ELF-Binärdateien als Quellcode auf Abruf.

In einem konkreten Beispiel mit WSL, bei dem sich der Benutzercode unter C:\Users\Bob\Sie könnten WinDbg Folgendes mitteilen:

Befehl: .sympath C:\Users\Bob\
.srcpath C:\Users\Bob\

Und wenn Sie DebugInfoD auch für Systembinärdateien verwenden möchten:

Befehl: .sympath+ DebugInfoD*https://debuginfod.elfutils.org
.srcpath+ DebugInfoD*https://debuginfod.elfutils.org

Mit dieser Konfiguration, wenn Sie den Stack untersuchen oder libc-Funktionen aufrufenWinDbg kann versuchen, die entsprechenden DWARF-Symbole herunterzuladen und, falls der Server den Code ebenfalls bereitstellt, den Quellcode sehr detailliert anzuzeigen, obwohl die Windows-Toolchain intern ELF und DWARF nicht so "nativ" verarbeitet wie PE und PDB.

Praktisches Beispiel: Debuggen eines C++-Programms mit gdbserver und WinDbg

Ein anschauliches Beispiel ist eine kleine C++-Anwendung, die eine Begrüßung auf dem Bildschirm ausgibt., kompiliert in WSL mit Debug-Symbolen. Stellen Sie sich ein Programm vor, das reserviert std::array<wchar_t, 50> und kopiert eine längere Nachricht hinein, wodurch der Text abgeschnitten wird und Zeichen erscheinen ???? am ende

Nach dem Kompilieren mit etwas wie:

Befehl: g++ DisplayGreeting.cpp -g -o DisplayGreeting

Sie starten gdbserver gegen diese Binärdatei.:

Befehl: gdbserver localhost:1234 DisplayGreeting

In WinDbg stellen Sie die Verbindung über die Zeichenkette her. gdb:server=localhost,port=1234 Sobald die Sitzung eingerichtet und die Symbol- und Schriftpfade konfiguriert sind, setzen Sie einen Haltepunkt in DisplayGreeting!mainSie können verwenden dx greeting Untersuchen Sie das lokale Array und sehen Sie sich seine Größe (50 Positionen) an. Überprüfen Sie visuell im Speicher-Tab oder in der Variablenansicht, wie die Begrüßung abgeschnitten wird.

Das Schöne an diesem Beispiel ist, dass es zeigt, dass selbst ohne vollständige Unterstützung für alle ELF/DWARF-Formate in WinDbgMit gdbserver als Remote-Backend können Sie Stacks durchlaufen, Typen untersuchen, Haltepunkte anhand von Funktionsnamen setzen und recht komfortabel durch C++-Code navigieren.

Debuggen des Linux-Kernels mit qemu und gdb

gdbserver wird nicht nur im Benutzermodus verwendet; es gibt auch sehr leistungsstarke Anwendungsszenarien im Kernelmodus.Insbesondere in Kombination mit Debugging-Unterstützung von QEMU. Obwohl hier die Rolle des „gdbservers“ durch eine QEMU-eigene Option übernommen wird, ist das Vorgehen identisch: Auf der einen Seite wird das zu debuggende System gestartet und ein gdb-Port geöffnet; auf der anderen Seite befindet sich entweder gdb oder ein Debugger, der das Remote-Protokoll unterstützt.

Um den Kernel zu debuggen, müssen Sie ihn mit spezifischen Debugging-Optionen kompilieren.: Aktivierung der Generierung von Debugging-Informationen (CONFIG_DEBUG_INFO), die GDB-Kernel-Skripte (CONFIG_GDB_SCRIPTS) und dem eigenen Debug-Modus des Kernels (CONFIG_DEBUG_KERNELEs ist außerdem wichtig, Optionen zu deaktivieren, die Symbole während des Linkens entfernen, wie z. B. „Assembler-generierte Symbole während des Linkens entfernen“.

Nach dem Kompilieren erhalten Sie eine Binärdatei. vmlinux „nicht entkleidet“Das ist diejenige, die Sie von gdb verwenden werden. Sie benötigen außerdem ein einfaches initramfs, das Sie mit einem Befehl wie diesem generieren können:

Befehl: mkinitramfs -o ramdisk.img

Dann starten Sie QEMU mit Debugging-Parametern.Ein typisches Beispiel ist die Option -gdb tcp::1234 einen gdb-kompatiblen Remote-Endpunkt öffnen, und -S sodass die virtuelle Maschine von Anfang an pausiert startet. Sie geben außerdem den Kernel an mit -kernel vmlinuxist die -initrd ramdisk.img, die Erinnerung mit -m 512 und normalerweise leitet man die Konsole um zu ttyS0 alles von der Terminal.

QEMU hält sich in Untersuchungshaft und wartet auf gdbVom Host-Rechner aus starten Sie gdb und geben dabei Folgendes ein: vmlinux und Sie verbinden sich mit target remote localhost:1234Von dort aus können Sie frühzeitig Haltepunkte festlegen, zum Beispiel einen hb start_kernelund die Ausführung mit Befehlen wie diesen steuern c (Fortfahren) und STRG+C, um erneut anzuhalten.

Jüngste Änderungen und Nuancen in gdb und gdbserver

In modernen Distributionen wie Red Hat Enterprise Linux 8 gibt es eine Reihe von Änderungen in gdb und gdbserver, die man beachten sollte.insbesondere wenn Sie von früheren Versionen kommen oder Skripte haben, die die Debugger-Ausgabe analysieren.

Zum einen startet gdbserver nun die „untergeordneten“ Prozesse über eine Shell.Genau wie gdb ermöglicht dies die Variablenerweiterung und -ersetzung in der Befehlszeile. Falls Sie dieses Verhalten aus irgendeinem Grund deaktivieren müssen, finden Sie in der Dokumentation von RHEL 8 entsprechende Einstellungen, um zum vorherigen Modus zurückzukehren.

Außerdem wurden einige Dinge entfernt oder geändert.: Debugging-Unterstützung für Java-Programme, die mit gcj, der HP-UX XDB-Kompatibilitätsmodus, Befehle wie set remotebaud (ersetzt durch set serial baudoder Kompatibilität mit einem bestimmten älteren Format von stabsDes Weiteren erfolgt die Thread-Nummerierung nicht mehr global, sondern anhand des „unteren“ Threads und erscheint als inferior_num.thread_num, mit neuen Komfortvariablen wie $_gthread auf den globalen Bezeichner verweisen.

Ein weiteres relevantes neues Merkmal ist die Anpassung max-value-sizeDies begrenzt die Speichermenge, die gdb für die Anzeige des Inhalts eines Wertes reservieren kann. Der Standardwert beträgt 64 KiB. Versuche, sehr große Arrays oder umfangreiche Strukturen auszugeben, können daher zu einer Warnung „Wert zu groß“ führen, anstatt den gesamten verfügbaren Speicher anzuzeigen.

Auch die Art und Weise, wie gdb mit den sysrootDer Standardwert ist jetzt target:Das bedeutet, dass bei Remote-Prozessen zuerst versucht wird, Bibliotheken und Symbole auf dem Zielsystem zu finden. Wenn lokale Symbole Priorität haben sollen, sollten Sie Folgendes ausführen: set sysroot mit der Route, die Sie interessiert, bevor Sie target remote.

Bezüglich des Befehlsverlaufs wird nun folgende Umgebungsvariable verwendet: GDBHISTSIZE statt HISTSIZEDies ermöglicht es Ihnen, genau festzulegen, wie lange die in Debugging-Sitzungen eingegebenen Befehle gespeichert werden sollen, ohne das Verhalten anderer Anwendungen zu beeinträchtigen, die die Zeilenlesebibliothek verwenden.

Workflow-Tipps und Fehlerbehebung mit gdbserver

Für einen komfortablen Arbeitsablauf gibt es einige Vorgehensweisen, die sich in der Regel sehr bewährt haben. Bei der Entwicklung für eingebettete Systeme oder Remote-Server besteht der erste Schritt darin, die Symbolkompilierung und die Binärbereitstellung auf dem Zielsystem so weit wie möglich zu automatisieren. Dadurch ist stets bekannt, welche Version der ausführbaren Datei ausgeführt wird, und die Symbolkopie ist auf dem Hostsystem jederzeit verfügbar.

In Umgebungen mit vielen Crash-Cores lohnt es sich, den Umgang mit gdb im Batch-Modus zu erlernen., mit Flaggen wie --batch, --ex y -x um automatisch Befehle auf einer Liste von Kernen auszuführen und deren Backtraces aus Skripten zu verarbeiten (zum Beispiel in PythonDies ermöglicht es Ihnen, wiederholt auftretende Probleme schnell herauszufiltern, Fehler anhand des Stack-Traces zu gruppieren usw.

Wenn bei der Remote-Verbindung etwas schiefgeht, besteht die Option --debug gdbserver ist dein bester FreundWenn Sie beispielsweise einen Prozessserver mit Folgendem starten:

Befehl: gdbserver --debug --multi localhost:1234

Die gdbserver-Konsole zeigt detaillierte Protokolle der Vorgänge an. Auf der Ebene des Remote-Protokolls umfasst dies eingehende Pakete, Formatierungsfehler, Verbindungsprobleme usw. Dies ist sehr nützlich, wenn Ihr gdb-Server plötzlich die Verbindung trennt, ein Prozess abstürzt, sobald ein Haltepunkt gesetzt wird, oder Ihre Debug-GUI etwas sendet, das gdbserver nicht versteht.

In Kontexten wie einem TP-Link-Router, bei dem Sie gdbserver an einen kritischen Prozess anbinden, wie z. B. httpdEs kommt relativ häufig vor, dass bestimmte Haltepunkte Race Conditions oder Watchdogs erzeugen, die den Prozess beenden, wenn er im Debugger zu lange „hängt“. In solchen Fällen kann es erforderlich sein, die blockierten Signale und die überwachten Threads anzupassen und gegebenenfalls die Systemkonfiguration (Timeout-Zeiten, Hardware-Watchdogs) zu modifizieren, um längere Debugging-Sitzungen zu ermöglichen.

Die effektive Nutzung von gdbserver erfordert die Kombination mehrerer Komponenten.Kompilieren Sie mit den passenden Symbolen, wählen Sie das richtige gdb für die Architektur, konfigurieren Sie Symbol- und Quellpfade, verstehen Sie die beiden Hauptmodi von gdbserver (Einzelprozess- und Mehrprozessbetrieb) und scheuen Sie sich nicht, aus dem Modus zu pullen. --debug Wenn die Verbindung nicht wie erwartet funktioniert. Mit dieser Grundlage wird das Debuggen von Anwendungen, die auf einem entfernten Linux-System, einem Router oder einer virtuellen Maschine mit einem benutzerdefinierten Kernel laufen, vom eigenen PC aus zur Routine und vor allem unglaublich nützlich.