Si të përdorni gdbserver për debugging në distancë në Linux

Nëse programoni në C ose C++ në Linux dhe nuk e ke prekur kurrë gdbserver-inPo humbisni një nga mjetet më të dobishme për debugging të proceseve në distancë, qoftë në një server, një sistem të integruar, apo edhe brenda një makine virtuale apo WSL. Larg nga të qenit diçka "magjike" ose e rezervuar për ekspertët, gdbserver është thjesht një program i vogël që komunikon me gdb dhe kontrollon ekzekutimin e procesit të synuar.

Ideja kryesore është shumë e thjeshtë.: në makinën ku po ekzekutohet skedari binar që dëshironi të debugoni (i objektiv) ju filloni gdbserver; në kompjuterin tuaj të punës (the mikpritësJu e nisni gdb ose edhe WinDbg me mbështetje për protokollin gdb. Të dyja lidhen nëpërmjet TCP ose një porte seriale, dhe prej andej mund të vendosni pika ndërprerjeje, të inspektoni variablat, të shikoni pirgun ose të ndiqni ekzekutimin hap pas hapi sikur programi të ishte duke u ekzekutuar në makinën tuaj.

Çfarë është gdbserver dhe kur ka kuptim ta përdorim?

gdbserver është një "agjent" i debuggingut në distancë për GNU gdbFunksioni i tij është shumë specifik: ai ekzekutohet në makinën ku ekzekutohet programi që do të analizohet, kontrollon atë proces (ose procese) dhe komunikon me një klient gdb të vendosur në një makinë tjetër (ose në të njëjtën makinë) përmes një lidhjeje në distancë.

Në përdorimin e përditshëm, gdbserver përdoret në dy skenarë tipikëSoftuer për debugim që funksionon në mjedise të integruara (routerë, borde me Linux të thjeshtuar, pajisje) IOTetj.) dhe proceset e debugimit në makinat e largëta Linux, ku nuk është e përshtatshme ose thjesht nuk është e mundur të kesh një gdb "të trashë" me të gjitha bibliotekat dhe simbolet.

Në një nivel praktik, gdbserver merret me detyra të tilla si Lexoni dhe shkruani regjistrat e procesit dhe memorien, kontrolloni ekzekutimin (vazhdoni, ndaloni, kaloni nëpër hapa), menaxhoni pikat e ndërprerjes dhe dërgoni të gjitha këto të dhëna në gdb duke përdorur protokollin e largët GDB. Kjo filozofi është shumë e ngjashme me atë të mjeteve si OpenOCD, të cilat veprojnë si një urë midis gdb dhe një hardware i jashtëm, me ndryshimin që gdbserver funksionon në të njëjtin sistem ku funksionon skedari binar.

Nëse vini nga mjedise Dritaret Është gjithashtu interesante të dish Debuggerët si WinDbg mund të komunikojnë me një gdbserver në Linux, kështu që ju mund të debugoni proceset e përdoruesit në Linux nga WinDbg duke përdorur mbështetjen e debuggimit në distancë nëpërmjet protokollit gdb që Microsoft ka përfshirë në versionet e fundit.

Kërkesat themelore për debugging me gdb dhe gdbserver

Para se të filloni debugging-un nga distanca, duhet të kuptoni marrëdhënien host/target.. objektiv Është makina ku ekzekutohet programi që do të debugohet dhe ku do të ekzekutohet gdbserver; mikpritës Kjo është makina nga e cila do të ekzekutoni gdb (ose WinDbg) dhe ku do të keni kodin burimor dhe, mundësisht, simbolet e debugging-ut.

Pika fillestare thelbësore është kompilimi i sistemit binar me simboleNë GCC ose g++ kjo arrihet me flamurin -gdhe zakonisht këshillohet që të çaktivizohen edhe optimizimet (për shembull me -O0Kjo i lejon debugger-it të shfaqë më saktë variablat, makrot dhe strukturën e kodit. Për makro specifike, mund të përdorni nivele më të larta debugging-u, si p.sh. -g3.

Nga ana e hostit do t'ju duhet një version i pajtueshëm i gdb me arkitekturën e synuar. Për të debuguar një sistem të integruar MIPS, ARM ose një arkitekturë tjetër, duhet të përdorni gdb-në e zinxhirit përkatës të mjeteve ndër-mjetës (për shembull) arm-none-eabi-gdb o gdb-multiarch) dhe, nëse është e nevojshme, konfiguroni arkitekturën dhe endianness-in me komandat si set arch y set endian.

Lidhur me lidhjen, gdbserver mbështet dy lloje kryesoreNjë lidhje seriale (shumë e zakonshme në pajisjet e integruara, nëpërmjet UART) dhe TCP/IP, e cila është më e përshtatshme kur objektivi është në të njëjtin rrjet ose është një makinë Linux e aksesueshme nëpërmjet rrjetit. Në të dyja rastet, komanda përdoret nga gdb. target remote për t'u lidhur me pikën fundore të ekspozuar nga gdbserver.

Mënyrat për të nisur gdbserver: modaliteti me një proces të vetëm dhe modaliteti me shumë procese

gdbserver mund të funksionojë në dy mënyra kryesore Kur flasim për debugging në modalitetin e përdoruesit: i lidhur drejtpërdrejt me një proces të vetëm ose si një "server procesi" që lejon renditjen dhe lidhjen me procese të ndryshme të sistemit.

Në modalitetin me një proces të vetëm Ju hapni gdbserver, duke specifikuar host:port dhe programin që do të ekzekutohet. Në një shembull të thjeshtë në një kompjuter desktop Linux, mund të bëni diçka të tillë:

Komanda: gdbserver localhost:3333 foo

Me atë komandë, gdbserver fillon skedarin binar. foo dhe ai qëndron duke dëgjuar në portin 3333Derisa të lidhet një gdb e largët, programi mbetet i ndaluar; kur gdb lidhet me target remote localhost:3333, procesi fillon të kontrollohet nga detyruesi i thërrmimit.

Në modalitetin me shumë procese (serveri i procesit) përdoret opsioni --multiNë këtë rast, gdbserver nuk nis drejtpërdrejt ndonjë program, por thjesht dëgjon për lidhje hyrëse dhe i lejon klientit (gdb ose WinDbg) të menaxhojë se cilin proces të krijojë ose t'i bashkëngjitë:

Komanda: gdbserver --multi localhost:1234

Kur punoni me WinDbg në Linux, kjo shumëmodalitet është veçanërisht interesante.Sepse nga vetë WinDbg mund të listoni proceset në sistemin e largët, të shihni PID-in, përdoruesin dhe rreshtin e komandës dhe t'i bashkëngjitni atij që ju intereson, në një mënyrë të ngjashme me atë që bëhet me serverin e proceseve. dbgsrv.exe në Windows.

Debugging në distancë me gdbserver dhe gdb hap pas hapi

Le ta shpjegojmë këtë me një shembull shumë tipik.Debugoni një aplikacion të thjeshtë në të njëjtën makinë (hosti dhe objektivi përputhen) duke përdorur gdbserver për të simuluar skenarin në distancë.

Së pari shkruani dhe kompiloni një program të vogëlPër shembull, një cikël qesharak që printon një numërues:

Komanda: gcc -g foo.c -o foo

Çelësi këtu është flamuri -gKjo shton informacionin e nevojshëm të debuggingut në skedarin binar në mënyrë që gdb të mund të shfaqë rreshta kodi, emra variablash, lloje etj. Në një mjedis "real" të përpilimit të kryqëzuar, do ta bënit këtë përpilim me zinxhirin e mjeteve të kryqëzuara dhe më pas do ta kopjonit si skedarin binar ashtu edhe varësitë e tij në objektiv.

Hapi tjetër është të nisni gdbserver në objektivNëse hosti dhe objektivi janë e njëjta makinë, atëherë:

Komanda: gdbserver localhost:3333 foo

Do të shihni një mesazh të ngjashëm me “Procesi foo u krijua; pid = XXXX; Duke dëgjuar në portin 3333”. Kjo tregon që gdbserver ka krijuar procesin dhe po pret që gdb të lidhet. Nëse jeni në një sistem ku kërkohen më shumë privilegje (për shembull, për t'u lidhur me proceset e sistemit), mund t'ju duhet të ekzekutoni komandën me sudoPor është gjithmonë e mençur të jesh i kujdesshëm kur jep leje. rrënjë te desulfurizuesi.

Në host, ju filloni gdb duke specifikuar skedarin ekzekutues lokal. (i njëjti që po ekzekutohet në objektiv, ose një kopje identike me simbole):

Komanda: gdb foo

Pasi të hyni në gdb, krijoni lidhjen në distancë me:

Komanda: target remote localhost:3333

Në atë pikë, gdb ngarkon simbolet nga binarja lokale.Sinkronizohet me gdbserver dhe merr kontrollin e procesit që është duke u ekzekutuar në të vërtetë nën gdbserver. Nga aty, rrjedha është ajo e zakonshme: komanda si break për të vendosur pika kthese, continue, step, next, print për të inspektuar variablat, backtrace për të parë baterinë, etj.

Lidhja me proceset në ekzekutim me gdbserver

Nuk është gjithmonë e nevojshme ta nisësh programin nga e para.Shpesh jeni të interesuar të bashkoheni me një proces që është tashmë në ekzekutim (për shembull, një httpd një routernjë daemon sistemi ose një shërbim prodhimi).

Modeli tipik është të përdoret opsioni --attach nga gdbserverduke kaluar portin ku do të dëgjojë dhe PID-in e procesit të synuar. Për shembull, në një router ku keni kopjuar një gdbserver të kompiluar për arkitekturën e tij, mund të bëni:

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

Nga ana e hostit, do të përdorni një version të gdb që mbështet arkitekturën e routerit., për shembull gdb-multiarchkonfigurimi i arkitekturës dhe endianness paraprakisht:

Komanda: set arch mips
set endian big

Pastaj specifikoni skedarin lokal që përmban simbolet. të binarit të largët (për shembull file httpd) dhe, nëse është e nevojshme, i tregoni gdb-së se ku po ekzekutohet në të vërtetë skedari binar në objektiv me set remote exec-file /usr/bin/httpdMë në fund, ashtu si më parë, ju lidheni me:

Komanda: target remote 192.168.0.1:3333

Pasi të jetë bashkangjiturMund të vendosni pika ndërprerjeje në funksione specifike (për shembull break checkFirmware), vazhdoni ekzekutimin dhe lejoni që rrjedha normale e programit (për shembull, ngarkimi i firmware-it nga ndërfaqja e internetit) të shkaktojë pikën e ndërprerjes.

Përdorimi i gdbserver me WinDbg në Linux

Vitet e fundit, Microsoft ka shtuar mbështetje për debugging-un e proceseve Linux në WinDbg. Duke përdorur gdbserver si backend. Ky funksionalitet është menduar për skenarë ku punoni në Windows, por kodi funksionon në Linux (përfshirë WSL).

Për të debuguar një proces specifik Linux me WinDbg duke përdorur gdbserverRrjedha do të ishte diçka e tillë: së pari ju lokalizoni procesin e synuar në makinën Linux me një komandë si ps -A (për shembull një python3 që është duke u ekzekutuar), atëherë ju hapni gdbserver në objektiv:

Komanda: gdbserver localhost:1234 python3

Nëse mjedisi e kërkon, mund t'ju duhet të përdorni sudo gdbserver ...me të njëjtat masa paraprake sigurie si gjithmonë. Pasi gdbserver tregon se po “Dëgjon në portin 1234”, në WinDbg shkoni te “File / Connect to remote debugger” dhe specifikoni një varg lidhjeje të tipit të mëposhtëm:

Komanda: gdb:server=localhost,port=1234

WinDbg përdor një "driver" të vogël protokolli gdb për të komunikuar me gdbserver. dhe, pasi të vendoset lidhja, ajo mbetet e ndaluar në pikën e boot të procesit. Nga aty mund të përdorni dritaret e tij të grumbullit, modulet, memorien, pikat e ndërprerjes, si dhe komandat si k për të parë baterinë ose lm për të listuar modulet (duke pasur parasysh se disa komanda presin formatin PE dhe jo ELF, kështu që ato mund të shfaqin të dhëna të çuditshme në raste të caktuara).

gdbserver dhe serveri i procesit WinDbg

Përveç rastit me një proces të vetëm, WinDbg mund të lidhet me një gdbserver duke vepruar si një server procesi. për të funksionuar në mënyrë më të ngjashme me mënyrën se si funksionon me proceset e largëta të Windows. Në këtë modalitet, gdbserver hapet me --multi dhe pa një proces të lidhur:

Komanda: sudo gdbserver --multi localhost:1234

Nga WinDbg, zgjidhni "File / Connect to proces server" dhe ju ripërdorni vargun e lidhjes gdb:server=localhost,port=1234Kur lidhja është aktive, mund të listoni proceset e disponueshme të Linux-it dhe t'i bashkëngjitni atij që dëshironi ose edhe të nisni një proces të ri.

Një detaj i vogël duhet të mbahet mend.WinDbg bën dallimin midis "serverit të procesit" dhe "objektivit të vetëm" në varësi të faktit nëse gdbserver është tashmë i lidhur me një proces kur ai lidhet. Nëse e keni lënë gdbserver të lidhur me një proces, e keni mbyllur WinDbg dhe më pas keni provuar të rilidheni, ai mund të mos zbulohet si një server procesi dhe mund t'ju duhet të rinisni gdbserver.

Për të përfunduar një seancë të serverit të procesitZakonisht, mjafton thjesht shtypja e CTRL+D në konsolën ku po ekzekutohet gdbserver dhe ndalimi i debugging-ut nga WinDbg. Në disa raste ekstreme, nëse ka probleme me sinkronizimin, mund të jetë e nevojshme të mbyllni plotësisht debugger-in dhe të rinisni gdbserver nga e para.

Menaxhimi i simboleve dhe kodit burimor në debugging në distancë

Një nga çelësat për ta bërë debugging-un në distancë të përshtatshëm është që simbolet dhe fontet të jenë të zgjidhura mirë.Pa simbole, navigimi në pirg ose vendosja e pikave të ndërprerjes në funksione specifike bëhet torturë.

Në skenarët klasikë gdb + gdbserver, është ideale të mbash një kopje të skedarit ekzekutues me simbole në host. (i pastripped) dhe pema burimore. gdb nuk kërkon që skedari binar i largët të përmbajë simbolet; mjafton që skedari lokal me të cilin ngarkoni file përputh skedarin ekzekutues të largët në nivelin e zhvendosjes.

Në botën e debugging-ut në WinDbg dhe Linux, kanë dalë edhe shërbime si DebugInfoD.të cilat ekspozojnë simbole dhe fonte mbi HTTP. WinDbg mund të përdorë shtigje të veçanta të tipit DebugInfoD*https://debuginfod.elfutils.org të dyja në .sympath si në .srcpath për të shkarkuar simbolet DWARF sipas kërkesës dhe kodin burimor të skedarëve binarë Linux ELF.

Në një shembull specifik me WSL, ku kodi i përdoruesit është nën C:\Users\Bob\Mund t’i thuash WinDbg-ut:

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

Dhe nëse doni të përdorni DebugInfoD edhe për skedarët binare të sistemit:

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

Me këtë konfigurim, kur inspektoni pirgun ose futni funksione libcWinDbg mund të përpiqet të shkarkojë simbolet përkatëse DWARF dhe, nëse serveri ekspozon edhe kodin, ta shfaqë burimin me detaje të konsiderueshme, megjithëse në brendësi, zinxhiri i mjeteve të Windows nuk i trajton ELF dhe DWARF aq "natyrshëm" sa PE dhe PDB.

Shembull praktik: debugging i një programi C++ me gdbserver dhe WinDbg

Një shembull ilustrues është një aplikacion i vogël C++ që shkruan një përshëndetje në ekran., i kompiluar në WSL me simbole debugging. Imagjinoni një program që rezervon një std::array<wchar_t, 50> dhe kopjon një mesazh më të gjatë në të, duke bërë që teksti të shkurtohet dhe të shfaqen karaktere ???? në fund

Pas kompilimit me diçka si:

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

Ju e nisni gdbserver kundër atij binar:

Komanda: gdbserver localhost:1234 DisplayGreeting

Në WinDbg ju lidheni me vargun gdb:server=localhost,port=1234 Dhe, pasi të jetë vendosur seanca dhe të jenë konfiguruar shtigjet e simboleve dhe shkronjave, ju vendosni një pikë ndërprerjeje në DisplayGreeting!mainju mund të përdorni dx greeting për të inspektuar vargun lokal dhe për të parë madhësinë e tij (50 pozicione), dhe për të kontrolluar vizualisht në skedën e memories ose në variablat shikoni se si pritet përshëndetja.

Bukuria e këtij shembulli është se tregon se, edhe pa mbështetje të plotë për të gjitha formatet ELF/DWARF në WinDbgMund të përshkoni stiva, të inspektoni llojet, të vendosni pikat e ndërprerjes sipas emrit të funksionit dhe të lundroni nëpër kodin C++ në mënyrë mjaft të rehatshme duke përdorur gdbserver si një backend të largët.

Debugimi i kernelit Linux me qemu dhe gdb

gdbserver nuk përdoret vetëm në modalitetin e përdoruesit; ka edhe skenarë shumë të fuqishëm në modalitetin e kernelit.Sidomos kur kombinoni QEMU-në me mbështetjen për debugging. Edhe pse këtu roli i "gdbserver" përmbushet nga opsioni i vetë QEMU-së, qasja është identike: njëra anë ekzekuton sistemin që do të debugohet dhe hap një port gdb; ana tjetër është ose gdb ose një debugger që flet protokollin në distancë.

Për të debuguar kernelin, duhet ta kompiloni atë me opsione specifike debugging.: aktivizo gjenerimin e informacionit të debugging-ut (CONFIG_DEBUG_INFO), skriptet e bërthamës GDB (CONFIG_GDB_SCRIPTS) dhe modaliteti i debugimit të vetë kernelit (CONFIG_DEBUG_KERNELËshtë gjithashtu e rëndësishme të çaktivizohen opsionet që heqin simbolet gjatë lidhjes, siç është "Hiq simbolet e gjeneruara nga assembleri gjatë lidhjes".

Pas kompilimit do të merrni një skedar binar vmlinux “jo i zhveshur”i cili është ai që do të përdorni nga gdb. Ju gjithashtu keni nevojë për një initramfs bazë, të cilin mund ta gjeneroni me një komandë si:

Komanda: mkinitramfs -o ramdisk.img

Pastaj filloni QEMU-në me parametrat e debugging-utNjë shembull tipik përfshin opsionin -gdb tcp::1234 për të hapur një pikë fundore të largët të pajtueshme me gdb, dhe -S në mënyrë që makina virtuale të fillojë e ndaluar nga fillimi. Gjithashtu specifikoni kernelin me -kernel vmlinux, -initrd ramdisk.img, kujtesa me -m 512 dhe zakonisht e ridrejtoni konsolën te ttyS0 për të menaxhuar gjithçka nga terminal.

Me QEMU të ndaluar në pritje të gdbNga makina pritëse, ju filloni gdb duke treguar te vmlinux dhe ti lidhesh me target remote localhost:1234Nga aty mund të vendosni pika të hershme ndërprerjeje, për shembull një hb start_kerneldhe kontrolloni ekzekutimin me komanda të tilla si c (vazhdoni) dhe CTRL+C për të ndaluar përsëri.

Ndryshimet dhe nuancat e fundit në gdb dhe gdbserver

Në shpërndarjet moderne si Red Hat Enterprise Linux 8, ka një numër ndryshimesh në gdb dhe gdbserver që ia vlen të mbahen mend.Sidomos nëse vini nga versione të mëparshme ose keni skripte që analizojnë rezultatin e debugger-it.

Nga njëra anë, gdbserver tani fillon proceset "më të ulëta" duke përdorur një shell.Ashtu si gdb, kjo lejon zgjerimin dhe zëvendësimet e variablave në rreshtin e komandës. Nëse për ndonjë arsye duhet ta çaktivizoni këtë sjellje, ka cilësime specifike të dokumentuara në RHEL 8 për t'u rikthyer në modalitetin e mëparshëm.

Disa gjëra janë hequr ose ndryshuar gjithashtu: mbështetje për debugging për programet Java të kompiluara me gcj, modaliteti i pajtueshmërisë HP-UX XDB, komanda të tilla si set remotebaud (zëvendësuar nga set serial baud) ose përputhshmëri me një format të caktuar më të vjetër të stabsPër më tepër, numërimi i fijeve nuk është më global, por sipas fijes "më të ulët", dhe shfaqet si inferior_num.thread_num, me variabla të rinj komoditeti si p.sh. $_gthread për t'iu referuar identifikuesit global.

Një tjetër veçori e re relevante është rregullimi max-value-sizeKjo kufizon sasinë e memories që gdb mund të ndajë për të shfaqur përmbajtjen e një vlere. Vlera parazgjedhur është 64 KiB, kështu që përpjekjet për të printuar vargje ose struktura masive mund të rezultojnë në një paralajmërim "vlera është shumë e madhe" në vend që të shfaqet e gjithë memories së disponueshme.

Gjithashtu është rregulluar mënyra se si gdb trajton sysrootVlera e parazgjedhur është tani target:Kjo do të thotë që për proceset në distancë, së pari do të përpiqet të gjejë librari dhe simbole në sistemin e synuar. Nëse doni që të përparësojë simbolet lokale, duhet të ekzekutoni set sysroot me rrugën që ju intereson përpara se ta bëni target remote.

Lidhur me historikun e komandave, variabli i mjedisit që përdoret tani është GDBHISTSIZE në vend të HISTSIZEKjo ju lejon të përcaktoni me hollësi se për sa kohë dëshironi të ruani komandat që keni shtypur në seancat e debuggingut pa ndërhyrë në sjelljen e aplikacioneve të tjera që përdorin bibliotekën e leximit të rreshtave.

Këshilla për rrjedhën e punës dhe zgjidhjen e problemeve me gdbserver

Për të pasur një rrjedhë pune të rehatshme, ekzistojnë disa modele që kanë tendencë të funksionojnë shumë mirë. Kur zhvilloni për sisteme të integruara ose servera të largët, hapi i parë është automatizimi i përpilimit të simboleve dhe vendosjes së skedarëve binarë në objektiv sa më shumë që të jetë e mundur. Në këtë mënyrë, ju gjithmonë e dini se cili version i skedarit ekzekutues po funksionon dhe e keni kopjen e simbolit të disponueshme lehtësisht në host.

Në mjedise me shumë bërthama që pësojnë aksidente, ia vlen të mësosh se si të përdorësh gdb në modalitetin batch., me flamuj si --batch, --ex y -x për të nisur automatikisht komandat në një listë bërthamash dhe për të përpunuar gjurmët e tyre nga skriptet (për shembull në PitonKjo ju lejon të filtroni shpejt problemet e përsëritura, të gruponi dështimet sipas gjurmës së pirgut, etj.

Kur diçka shkon keq me lidhjen në distancë, opsioni --debug gdbserver është shoku juaj më i mirëNëse filloni, për shembull, një server procesesh me:

Komanda: gdbserver --debug --multi localhost:1234

Konsola e gdbserver do të tregojë gjurmë të detajuara të asaj që po ndodh Në nivelin e protokollit në distancë, kjo përfshin paketat hyrëse, gabimet e formatimit, problemet e shkëputjes, etj. Kjo është shumë e dobishme kur serveri juaj gdb shkëputet papritur, një proces rrëzohet sapo vendoset një pikë ndërprerjeje, ose ndërfaqja juaj grafike e debugimit dërgon diçka që gdbserver nuk e kupton.

Në kontekste të tilla si një router TP-Link ku ju lidhni gdbserver me një proces kritik si httpdËshtë relativisht e zakonshme që disa pika ndërprerjeje të krijojnë kushte gare ose mbikëqyrës që e ndërpresin procesin kur ai mbetet "i bllokuar" për një kohë shumë të gjatë në debugger. Në këto situata, mund të jetë e nevojshme të rregulloni se cilat sinjale bllokohen, cilat fije kontrollohen dhe, nëse është e aplikueshme, të modifikoni vetë konfigurimin e sistemit (kohët e skadimit, mbikëqyrësit e harduerit) për të lejuar seanca më të gjata të debugimit.

Përdorimi i mirë i gdbserver përfshin kombinimin e disa pjesëveKompiloni me simbole të përshtatshme, zgjidhni gdb-në e saktë për arkitekturën, konfiguroni shtigjet e simboleve dhe të burimit, kuptoni dy mënyrat kryesore të gdbserver (një proces dhe shumë proces) dhe mos kini frikë të tërhiqni nga mënyra. --debug kur lidhja nuk sillet siç pritet. Me këtë bazë, debugging-u i aplikacioneve që funksionojnë në një sistem të largët Linux, një router ose një makinë virtuale me një kernel të personalizuar nga PC-ja juaj bëhet mjaft rutinë dhe, mbi të gjitha, tepër i dobishëm.