리눅스에서 gdbserver를 사용하여 원격 디버깅하는 방법

C나 C++로 프로그래밍을 한다면 Linux 그리고 당신은 gdbserver를 한 번도 사용해 본 적이 없군요.서버, 임베디드 시스템, 심지어 가상 머신이나 WSL 환경에서도 원격으로 프로세스를 디버깅하는 데 가장 유용한 도구 중 하나를 놓치고 계신 겁니다. gdbserver는 전문가만을 위한 특별한 프로그램이 아니라, gdb와 통신하고 대상 프로세스의 실행을 제어하는 ​​간단한 프로그램입니다.

핵심 아이디어는 매우 간단합니다.디버깅하려는 바이너리가 실행 중인 머신에서 목표) 업무용 컴퓨터( 주인gdb 또는 gdb 프로토콜을 지원하는 WinDbg를 실행합니다. 두 프로그램 모두 TCP 또는 직렬 포트를 통해 연결되며, 연결 후에는 중단점을 설정하고, 변수를 검사하고, 스택을 확인하고, 마치 프로그램이 자신의 컴퓨터에서 실행되는 것처럼 단계별로 실행 과정을 추적할 수 있습니다.

gdbserver란 무엇이며, 언제 사용하는 것이 적절할까요?

gdbserver는 GNU gdb용 원격 디버깅 "에이전트"입니다.그 기능은 매우 구체적입니다. 분석 대상 프로그램이 실행되는 컴퓨터에서 실행되어 해당 프로세스(또는 프로세스들)를 제어하고, 원격 연결을 통해 다른 컴퓨터(또는 같은 컴퓨터)에 있는 gdb 클라이언트와 통신합니다.

일상적인 사용에서 gdbserver는 일반적으로 두 가지 시나리오에서 사용됩니다.임베디드 환경(라우터, 간소화된 Linux가 설치된 보드, 장치)에서 실행되는 소프트웨어 디버깅 만약 IoT(등) 그리고 모든 라이브러리와 심볼이 포함된 "용량이 큰" gdb를 사용하는 것이 불편하거나 불가능한 원격 Linux 시스템에서 프로세스를 디버깅하는 데 사용됩니다.

실질적으로 gdbserver는 다음과 같은 작업을 처리합니다. 프로세스 레지스터와 메모리를 읽고 쓰고, 실행을 제어(계속, 일시 중지, 단계별 실행), 중단점을 관리하고, 이 모든 데이터를 GDB 원격 프로토콜을 사용하여 gdb로 전송합니다. 이러한 방식은 gdb와 프로세스 레지스터 및 메모리 사이의 브리지 역할을 하는 OpenOCD와 같은 도구의 작동 방식과 매우 유사합니다. 하드웨어 외부 서버와 유사하지만, gdbserver는 바이너리가 실행되는 시스템과 동일한 시스템에서 실행된다는 점이 다릅니다.

만약 당신이 다른 환경에서 왔다면 Windows 이것도 알아두면 흥미롭습니다. WinDbg와 같은 디버거는 Linux의 gdbserver와 통신할 수 있으므로 Microsoft가 최근 버전에 통합한 gdb 프로토콜을 통한 원격 디버깅 지원을 사용하여 WinDbg에서 Linux의 사용자 프로세스를 디버깅할 수 있습니다.

gdb 및 gdbserver를 사용한 디버깅을 위한 기본 요구 사항

원격 디버깅을 시작하기 전에 호스트와 대상 간의 관계를 이해해야 합니다.. 목표 디버깅 대상 프로그램이 실행되는 머신이자 gdbserver가 실행되는 머신입니다. 주인 이 컴퓨터는 gdb(또는 WinDbg)를 실행하고 소스 코드와 (가능하다면) 디버깅 심볼을 보관할 곳입니다.

가장 중요한 출발점은 심볼을 사용하여 바이너리를 컴파일하는 것입니다.GCC 또는 g++에서는 플래그를 사용하여 이를 구현할 수 있습니다. -g또한 일반적으로 최적화 기능을 비활성화하는 것이 좋습니다(예: -O0이를 통해 디버거는 변수, 매크로 및 코드 구조를 더욱 정확하게 표시할 수 있습니다. 특정 매크로의 경우, 더 높은 디버깅 수준(예: ...)을 사용할 수 있습니다. -g3.

호스트 측에서는 호환되는 버전의 gdb가 필요합니다. 대상 아키텍처에 맞춰야 합니다. MIPS, ARM 또는 기타 아키텍처의 임베디드 시스템을 디버깅하려면 해당 크로스 툴체인의 gdb를 사용해야 합니다(예:). arm-none-eabi-gdb o gdb-multiarch그리고 필요한 경우 아키텍처 및 엔디안을 구성합니다. 명령 으로 set arch y set endian.

연결 방식과 관련하여 gdbserver는 크게 두 가지 유형을 지원합니다.직렬 링크(임베디드 하드웨어에서 UART를 통해 매우 흔하게 사용됨)와 TCP/IP 링크가 있습니다. TCP/IP 링크는 대상이 동일 네트워크에 있거나 네트워크를 통해 접근 가능한 Linux 시스템일 때 가장 편리합니다. 두 경우 모두 gdb에서 명령어를 사용합니다. target remote gdbserver에서 노출하는 엔드포인트에 연결합니다.

gdbserver 시작 방법: 단일 프로세스 모드 및 다중 프로세스 모드

gdbserver는 크게 두 가지 방식으로 작동할 수 있습니다. 사용자 모드 디버깅에 대해 이야기할 때, 단일 프로세스에 직접 연결되는 방식과 여러 시스템 프로세스를 나열하고 연결할 수 있는 "프로세스 서버" 방식이 있습니다.

단일 프로세스 모드에서 gdbserver를 실행할 때 호스트:포트와 실행할 프로그램을 지정합니다. 간단한 예로 Linux 데스크톱 컴퓨터에서는 다음과 같이 할 수 있습니다.

명령: gdbserver localhost:3333 foo

해당 명령어를 사용하면 gdbserver가 바이너리를 시작합니다. foo 그리고 그는 3333번 포트에서 계속 듣고 있습니다.원격 gdb가 연결될 때까지 프로그램은 정지된 상태로 유지됩니다. gdb가 연결되면 프로그램이 정상적으로 작동합니다. target remote localhost:3333그 후, 공정은 분쇄기에 의해 제어되기 시작합니다.

다중 프로세스 모드(프로세스 서버)에서 해당 옵션이 사용됩니다. --multi이 경우 gdbserver는 어떤 프로그램도 직접 실행하지 않고, 단순히 들어오는 연결을 수신 대기하며 클라이언트(gdb 또는 WinDbg)가 어떤 프로세스를 생성하거나 연결할지 관리하도록 합니다.

명령: gdbserver --multi localhost:1234

Linux에서 WinDbg를 사용할 때 이러한 멀티 모드는 특히 흥미롭습니다.WinDbg 자체에서 원격 시스템의 프로세스 목록을 보고, PID, 사용자 및 명령줄을 확인하고, 관심 있는 프로세스에 연결할 수 있기 때문입니다. 이는 프로세스 서버를 사용하는 방식과 유사합니다. dbgsrv.exe Windows에서.

gdbserver와 gdb를 이용한 원격 디버깅 단계별 가이드

아주 전형적인 예를 들어 설명해 보겠습니다.: gdbserver를 사용하여 원격 시나리오를 시뮬레이션하고 동일한 머신(호스트와 타겟이 일치)에서 간단한 애플리케이션을 디버깅합니다.

먼저 간단한 프로그램을 작성하고 컴파일합니다.예를 들어, 카운터를 출력하는 간단한 반복문은 다음과 같습니다.

명령: gcc -g foo.c -o foo

여기서 핵심은 깃발입니다. -g이렇게 하면 gdb가 코드 라인, 변수 이름, 데이터 유형 등을 표시할 수 있도록 필요한 디버깅 정보가 바이너리에 추가됩니다. "실제" 크로스 컴파일 환경에서는 크로스 툴체인을 사용하여 컴파일한 다음 바이너리와 해당 종속성을 대상 시스템으로 복사합니다.

다음 단계는 대상 시스템에서 gdbserver를 시작하는 것입니다.호스트와 타겟이 동일한 머신인 경우:

명령: gdbserver localhost:3333 foo

다음과 유사한 메시지가 표시됩니다. "프로세스 foo가 생성되었습니다. pid = XXXX; 3333번 포트에서 수신 대기 중입니다." 이는 gdbserver가 프로세스를 생성하고 gdb의 연결을 기다리고 있음을 나타냅니다. 시스템 프로세스에 연결하는 등 더 높은 권한이 필요한 시스템에서는 명령어를 실행할 때 추가 권한을 사용해야 할 수도 있습니다. sudo하지만 허가를 내줄 때는 항상 신중을 기하는 것이 현명합니다. 뿌리 탈황기로.

호스트에서 로컬 실행 파일을 지정하여 gdb를 시작합니다. (대상 시스템에서 실행 중인 것과 동일한 버전 또는 심볼이 포함된 동일한 복사본):

명령: gdb foo

gdb에 접속하면 원격 연결을 설정합니다.:

명령: target remote localhost:3333

이때 gdb는 로컬 바이너리에서 심볼을 로드합니다.gdbserver와 동기화되어 gdbserver에서 실제로 실행 중인 프로세스의 제어권을 가져옵니다. 그 후에는 일반적인 흐름대로 다음과 같은 명령어를 실행합니다. break 한계점을 설정하기 위해, continue, step, next, print 변수를 검사하려면, backtrace 배터리 등을 확인하기 위해

gdbserver를 사용하여 실행 중인 프로세스에 연결하기

프로그램을 처음부터 새로 설치하는 것이 항상 바람직한 것은 아닙니다.이미 진행 중인 프로세스에 참여하는 데 관심이 있는 경우가 많습니다(예: httpd 로 라우터시스템 데몬 또는 운영 서비스).

일반적인 패턴은 옵션을 사용하는 것입니다. --attach gdbserver에서수신 대기할 포트와 대상 프로세스의 PID를 전달합니다. 예를 들어, 해당 아키텍처에 맞게 컴파일된 gdbserver를 복사한 라우터에서는 다음과 같이 할 수 있습니다.

명령: gdbserver localhost:3333 --attach <pid_de_httpd>

호스트 측에서는 라우터의 아키텍처를 지원하는 버전의 gdb를 사용해야 합니다.예를 들어 gdb-multiarch아키텍처 및 엔디안 방식을 사전에 구성합니다.

명령: set arch mips
set endian big

그다음에는 심볼이 포함된 로컬 파일을 지정합니다. 원격 바이너리의 (예시) file httpd그리고 필요한 경우, gdb에게 대상 시스템에서 바이너리가 실제로 실행되는 위치를 알려줍니다. set remote exec-file /usr/bin/httpd마지막으로, 이전과 마찬가지로 다음과 연결됩니다.

명령: target remote 192.168.0.1:3333

일단 부착되면특정 함수에 중단점을 설정할 수 있습니다(예: break checkFirmware) 실행을 계속하고 프로그램의 정상적인 흐름(예: 웹 인터페이스에서 펌웨어 업로드)이 중단점을 트리거하도록 합니다.

Linux에서 WinDbg와 함께 gdbserver 사용하기

최근 몇 년 동안 마이크로소프트는 WinDbg에 Linux 프로세스 디버깅 지원을 추가했습니다. gdbserver를 백엔드로 사용합니다. 이 기능은 Windows 환경에서 작업하지만 코드는 Linux(WSL 포함)에서 실행되는 시나리오를 위해 설계되었습니다.

WinDbg와 gdbserver를 사용하여 특정 Linux 프로세스를 디버깅하려면절차는 대략 다음과 같습니다. 먼저 다음과 같은 명령어를 사용하여 Linux 시스템에서 대상 프로세스를 찾습니다. ps -A (예를 들어 python3 실행 중인 경우, 대상 시스템에서 gdbserver를 실행합니다.

명령: gdbserver localhost:1234 python3

환경적인 요구 사항이 있는 경우 사용해야 할 수도 있습니다. sudo gdbserver ...항상과 동일한 보안 조치를 취하십시오. gdbserver가 "포트 1234에서 수신 대기 중"이라고 표시되면 WinDbg에서 "파일 / 원격 디버거에 연결"로 이동하여 다음 형식의 연결 문자열을 지정하십시오.

명령: gdb:server=localhost,port=1234

WinDbg는 gdbserver와 통신하기 위해 작은 gdb 프로토콜 "드라이버"를 사용합니다. 그리고 연결이 설정되면 해당 지점에서 정지된 상태로 유지됩니다. 부팅 해당 프로세스의 스택 창, 모듈, 메모리, 중단점, 그리고 다음과 같은 명령어를 사용할 수 있습니다. k 배터리를 확인하거나 lm 모듈 목록을 보려면 (일부 명령은 ELF 형식이 아닌 PE 형식을 예상하므로 경우에 따라 이상한 데이터가 표시될 수 있다는 점에 유의하십시오).

gdbserver 및 WinDbg 프로세스 서버

WinDbg는 단일 프로세스 연결 외에도 프로세스 서버 역할을 하는 gdbserver에 연결할 수 있습니다. 원격 Windows 프로세스와 유사하게 작동하도록 하기 위함입니다. 이 모드에서 gdbserver는 다음과 같이 실행됩니다. --multi 관련 프로세스 없이:

명령: sudo gdbserver --multi localhost:1234

WinDbg에서 "파일 / 프로세스 서버에 연결"을 선택합니다. 그리고 연결 문자열을 재사용합니다. gdb:server=localhost,port=1234연결이 활성화되면 사용 가능한 Linux 프로세스 목록을 확인하고 원하는 프로세스에 연결하거나 새 프로세스를 실행할 수 있습니다.

한 가지 미묘한 점을 명심해야 합니다.WinDbg는 gdbserver가 연결 시점에 이미 프로세스에 연결되어 있는지 여부에 따라 "프로세스 서버"와 "단일 대상"을 구분합니다. gdbserver가 프로세스에 연결된 상태로 WinDbg를 종료한 후 다시 연결하려고 하면 프로세스 서버로 인식되지 않을 수 있으며, 이 경우 gdbserver를 다시 시작해야 할 수 있습니다.

프로세스 서버 세션을 종료하려면일반적으로 gdbserver가 실행 중인 콘솔에서 CTRL+D를 눌러 WinDbg에서 디버깅을 중지하는 것만으로 충분합니다. 하지만 동기화 문제가 발생하는 극단적인 경우에는 디버거를 완전히 종료하고 gdbserver를 처음부터 다시 시작해야 할 수도 있습니다.

원격 디버깅에서의 심볼 및 소스 코드 관리

원격 디버깅을 편리하게 만드는 핵심 요소 중 하나는 기호와 글꼴 부분을 제대로 해결하는 것입니다.심볼이 없으면 스택을 탐색하거나 특정 함수에 중단점을 설정하는 것이 매우 어려워집니다.

일반적인 gdb + gdbserver 시나리오에서는 실행 파일과 심볼 정보의 복사본을 호스트에 보관하는 것이 이상적입니다. (표백되지 않은) 소스 트리. gdb는 원격 바이너리에 심볼이 포함되어 있을 필요가 없습니다. 로드하는 로컬 파일에 심볼이 포함되어 있으면 충분합니다. file 오프셋 수준에서 원격 실행 파일과 일치합니다.

WinDbg와 Linux 디버깅 분야에서도 DebugInfoD와 같은 서비스가 등장했습니다.HTTP를 통해 기호와 글꼴을 노출하는 WinDbg는 다음과 같은 특수 경로를 사용할 수 있습니다. DebugInfoD*https://debuginfod.elfutils.org 모두 .sympath 에서와 같이 .srcpath 필요에 따라 DWARF 심볼과 Linux ELF 바이너리 소스 코드를 다운로드할 수 있습니다.

WSL의 구체적인 예를 들면, 사용자 코드가 아래에 있는 경우입니다. C:\Users\Bob\WinDbg에 다음과 같이 말할 수 있습니다.

명령: .sympath C:\Users\Bob\
.srcpath C:\Users\Bob\

시스템 바이너리에 대해서도 DebugInfoD를 사용하고 싶다면:

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

이 설정에서는 스택을 검사하거나 libc 함수에 진입할 때 다음과 같은 결과가 나타납니다.WinDbg는 해당 DWARF 심볼을 다운로드하려고 시도할 수 있으며, 서버에서 코드도 노출하는 경우 소스 코드를 상당히 자세하게 표시할 수 있습니다. 하지만 Windows 툴체인은 내부적으로 PE 및 PDB처럼 ELF 및 DWARF 형식을 "기본적으로" 처리하지는 않습니다.

실제 사례: gdbserver와 WinDbg를 이용한 C++ 프로그램 디버깅

예를 들어 화면에 인사말을 출력하는 간단한 C++ 애플리케이션을 생각해 볼 수 있습니다.디버깅 심볼을 포함하여 WSL에서 컴파일되었습니다. 특정 값을 예약하는 프로그램을 상상해 보세요. std::array<wchar_t, 50> 그리고 더 긴 메시지를 복사해서 붙여넣으면 텍스트가 잘리고 문자가 누락되는 현상이 발생합니다. ???? 결국

다음과 같은 것으로 컴파일한 후:

명령: g++ DisplayGreeting.cpp -g -o DisplayGreeting

해당 바이너리에 대해 gdbserver를 시작합니다.:

명령: gdbserver localhost:1234 DisplayGreeting

WinDbg에서는 문자열을 사용하여 연결합니다. gdb:server=localhost,port=1234 세션이 설정되고 심볼 및 글꼴 경로가 구성되면 중단점을 설정합니다. DisplayGreeting!main당신은 사용할 수 있습니다 dx greeting 로컬 배열을 검사하고 크기(50개 위치)를 확인하고, 메모리 탭이나 변수 보기에서 인사말이 어떻게 잘리는지 시각적으로 확인합니다.

이 예시의 묘미는 WinDbg에서 모든 ELF/DWARF 형식을 완벽하게 지원하지 않더라도 충분히 활용 가능하다는 것을 보여준다는 점입니다.gdbserver를 원격 백엔드로 사용하면 스택을 탐색하고, 유형을 검사하고, 함수 이름으로 중단점을 설정하고, C++ 코드를 비교적 편리하게 탐색할 수 있습니다.

qemu와 gdb를 이용한 리눅스 커널 디버깅

gdbserver는 사용자 모드에서만 사용되는 것이 아닙니다. 커널 모드에서도 매우 강력한 시나리오가 존재합니다.특히 QEMU를 디버깅 지원 기능과 결합할 때 그렇습니다. 여기서는 "gdbserver"의 역할이 QEMU 자체 옵션에 의해 수행되지만, 접근 방식은 동일합니다. 한쪽은 디버깅할 시스템을 실행하고 gdb 포트를 열고, 다른 한쪽은 gdb이거나 원격 프로토콜을 지원하는 디버거입니다.

커널을 디버깅하려면 특정 디버깅 옵션을 사용하여 컴파일해야 합니다.디버깅 정보 생성을 활성화합니다.CONFIG_DEBUG_INFO), GDB 커널 스크립트(CONFIG_GDB_SCRIPTS) 및 커널 자체의 디버그 모드(CONFIG_DEBUG_KERNEL또한 "링크 중에 어셈블러가 생성한 심볼 제거"와 같이 링크 중에 심볼을 제거하는 옵션을 비활성화하는 것도 중요합니다.

컴파일이 완료되면 바이너리 파일이 생성됩니다. vmlinux "벗겨지지 않음"gdb에서 사용할 initramfs도 필요합니다. 기본 initramfs는 다음과 같은 명령어로 생성할 수 있습니다.

명령: mkinitramfs -o ramdisk.img

그런 다음 디버깅 매개변수를 사용하여 QEMU를 시작합니다.대표적인 예로는 옵션이 있습니다. -gdb tcp::1234 gdb와 호환되는 원격 엔드포인트를 열려면, -S 이렇게 하면 가상 머신이 처음부터 일시 중지된 상태로 시작됩니다. 또한 커널을 지정합니다. -kernel vmlinux, -initrd ramdisk.img기억과 함께 -m 512 그리고 일반적으로 콘솔을 다음으로 리디렉션합니다. ttyS0 모든 것을 관리하기 위해 단말기.

QEMU는 gdb를 기다리며 억류되어 있습니다.호스트 머신에서 gdb를 실행하고 다음 경로를 지정합니다. vmlinux 그리고 당신은 연결됩니다 target remote localhost:1234여기에서 예를 들어 조기 중단점을 설정할 수 있습니다. hb start_kernel그리고 다음과 같은 명령어를 사용하여 실행을 제어합니다. c (계속)을 누르고 CTRL+C를 눌러 다시 일시 정지하세요.

gdb 및 gdbserver의 최근 변경 사항 및 세부적인 특징

Red Hat Enterprise Linux 8과 같은 최신 배포판에서는 gdb 및 gdbserver에 몇 가지 변경 사항이 있으므로 이를 염두에 두는 것이 좋습니다.특히 이전 버전에서 업그레이드했거나 디버거 출력을 분석하는 스크립트가 있는 경우 더욱 그렇습니다.

한편으로, gdbserver는 이제 셸을 사용하여 "하위" 프로세스를 시작합니다.gdb와 마찬가지로, 이 기능은 명령줄에서 변수 확장 및 치환을 허용합니다. 어떤 이유로든 이 동작을 비활성화해야 하는 경우, RHEL 8에 설명된 특정 설정을 사용하여 이전 모드로 되돌릴 수 있습니다.

또한 몇 가지 항목이 삭제되거나 변경되었습니다.: 컴파일된 Java 프로그램에 대한 디버깅 지원 gcjHP-UX XDB 호환 모드, 명령어 등 set remotebaud (다음으로 대체됨) set serial baud) 또는 특정 구형 형식과의 호환성 stabs또한, 스레드 번호 매기기는 더 이상 전역적으로 이루어지지 않고 "하위" 스레드별로 이루어지며 다음과 같이 표시됩니다. inferior_num.thread_num다음과 같은 새로운 편의 변수를 포함합니다. $_gthread 전역 식별자를 참조하기 위해.

또 다른 중요한 새 기능은 조정 기능입니다. max-value-size이는 gdb가 값의 내용을 표시하기 위해 할당할 수 있는 메모리 양을 제한합니다. 기본값은 64KiB이므로, 매우 큰 배열이나 구조체를 출력하려고 하면 사용 가능한 모든 메모리가 표시되는 대신 "값이 너무 큽니다"라는 경고가 나타날 수 있습니다.

gdb가 처리하는 방식도 조정되었습니다. sysroot기본값은 이제 다음과 같습니다. target:이는 원격 프로세스의 경우 대상 시스템에서 라이브러리와 심볼을 먼저 찾으려고 시도한다는 의미입니다. 로컬 심볼을 우선적으로 사용하도록 하려면 다음 명령을 실행해야 합니다. set sysroot 먼저 관심 있는 경로를 선택하세요. target remote.

명령 기록과 관련하여 현재 사용되는 환경 변수는 다음과 같습니다. GDBHISTSIZE 대신 HISTSIZE이 기능을 사용하면 디버깅 세션에서 입력한 명령을 유지할 기간을 세밀하게 조정할 수 있으며, 줄 읽기 라이브러리를 사용하는 다른 애플리케이션의 동작에는 영향을 주지 않습니다.

gdbserver 워크플로우 팁 및 문제 해결

원활한 작업 흐름을 위해서는 몇 가지 효과적인 패턴이 있습니다. 임베디드 시스템이나 원격 서버용 소프트웨어를 개발할 때 가장 먼저 해야 할 일은 심볼 컴파일과 바이너리 배포를 최대한 자동화하는 것입니다. 이렇게 하면 실행 파일의 어떤 버전이 실행 중인지 항상 알 수 있고, 호스트 시스템에서 심볼 복사본을 바로 사용할 수 있습니다.

크래시 코어가 많은 환경에서는 gdb를 배치 모드로 사용하는 방법을 배우는 것이 유용합니다.깃발과 함께 --batch, --ex y -x 스크립트에서 코어 목록에 대한 명령을 자동으로 실행하고 해당 백트레이스를 처리합니다(예: Python이를 통해 반복되는 문제를 신속하게 필터링하고, 스택 추적별로 오류를 그룹화하는 등의 작업을 수행할 수 있습니다.

원격 연결에 문제가 발생할 경우, 다음 옵션이 있습니다. --debug gdbserver는 당신의 최고의 친구입니다.예를 들어 다음과 같이 프로세스 서버를 시작하는 경우:

명령: gdbserver --debug --multi localhost:1234

gdbserver 콘솔에는 현재 상황에 대한 자세한 추적 정보가 표시됩니다. 원격 프로토콜 수준에서는 수신 패킷, 포맷 오류, 연결 끊김 문제 등을 확인할 수 있습니다. 이는 gdb 서버 연결이 갑자기 끊어지거나, 중단점을 설정하자마자 프로세스가 충돌하거나, 디버그 GUI에서 gdb 서버가 이해할 수 없는 데이터를 전송하는 경우에 매우 유용합니다.

TP-Link 라우터와 같이 gdbserver를 중요한 프로세스에 연결하는 경우와 같은 상황에서 httpd특정 중단점에서 경쟁 조건이 발생하거나 디버거에서 프로세스가 너무 오랫동안 "멈춰" 있을 때 프로세스가 종료되는 경우가 비교적 흔합니다. 이러한 상황에서는 차단할 신호, 제어할 스레드를 조정하고, 필요한 경우 시스템 구성(타임아웃 시간, 하드웨어 워치독) 자체를 수정하여 디버깅 세션을 연장해야 할 수 있습니다.

gdbserver를 제대로 사용하려면 여러 요소를 조합해야 합니다.적절한 심볼을 사용하여 컴파일하고, 아키텍처에 맞는 gdb를 선택하고, 심볼 및 소스 경로를 구성하고, gdbserver의 두 가지 주요 모드(단일 프로세스 및 다중 프로세스)를 이해하고, 해당 모드에서 코드를 가져오는 것을 두려워하지 마십시오. --debug 연결이 예상대로 작동하지 않을 때 유용합니다. 이러한 기반을 갖추면 원격 Linux 시스템, 라우터 또는 사용자 지정 커널이 설치된 가상 머신에서 실행되는 애플리케이션을 PC에서 디버깅하는 것이 매우 간편하고 무엇보다 엄청나게 유용해집니다.