GDB vs LLDB 분석 — 두 디버거의 설치·차이·선택 기준

#디버거가 실제로 하는 일

C/C++ 프로그램을 작성하다 보면 예상과 다르게 죽거나 의도와 다르게 도는 일을 매번 만납니다. printf로 잡을 수도 있지만:

• 죽는 자리를 모를 때는 printf를 어디에 넣어야 하나
• 미묘한 버그는 printf가 동작을 바꿔 사라질 수 있음 (Heisenbug)
• 변수가 언제 변하는지 printf로는 안 보임

디버거는 이 모든 문제를 푸는 도구입니다. 프로그램을 중간에 멈추고, 변수를 들여다보고, 원하는 시점부터 한 줄씩 실행합니다.

핵심 기능 다섯 가지로 줄이면:

1. Breakpoint — 특정 자리에 멈춤.
2. Step — 한 줄(또는 명령어)씩 진행.
3. Inspect — 변수, 메모리, 레지스터 보기.
4. Backtrace — 지금 어디까지 와서 멈췄는지 호출 사슬.
5. Modify — 변수 값을 디버거에서 직접 바꿔 가설 검증.

이 다섯 기능 위에 Watchpoint, Conditional break, Reverse exec, Remote, TUI, Python script 같은 고급 기능이 얹혀 있습니다.

#어떻게 멈추는가 — ptrace와 친구들

디버거가 다른 프로세스를 멈추고 조사할 수 있는 것은 운영체제가 그런 API를 제공하기 때문입니다.

#Linux — ptrace

1
#include <sys/ptrace.h>
2

3
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
4
// 이제 pid 프로세스가 STOPPED 상태
5
// 레지스터·메모리 읽기·쓰기 가능
6
ptrace(PTRACE_DETACH, pid, NULL, NULL);

GDB·LLDB 모두 *Linux에서는 ptrace*를 사용합니다. 이 한 시스템 콜이 디버거의 모든 마법의 근간.

ptrace가 하는 일:

• 다른 프로세스의 레지스터 읽기/쓰기.
• 메모리 읽기/쓰기 (디버거가 변수를 보거나 변경).
• 시스템 호출 추적 (strace도 같은 메커니즘).
• 시그널 가로채기 (SIGSEGV 등을 디버거가 먼저 받음).

#macOS — Mach API

macOS는 ptrace가 제한적입니다. 대신 Mach 메시지를 통해 같은 일을 합니다. LLDB가 macOS에서 사실상 표준인 이유 — Apple이 Mach 기반으로 LLDB를 가장 잘 통합.

#Windows — DebugActiveProcess

Windows는 또 다른 API. GDB·LLDB의 Windows 포트가 완벽하지 않은 이유.

이 시리즈는 Linux와 macOS에 집중합니다. Windows는 Visual Studio 디버거가 훨씬 잘 동작합니다.

#GDB와 LLDB — 같은 일, 다른 명령어

두 도구는 비슷한 기능을 다른 명령으로 제공합니다. 핵심 차이는 다음과 같습니다.

#자주 쓰는 명령 대조표

LLDB는 풀 명령이 길지만 alias가 거의 모든 GDB 명령에 대응합니다. GDB 사용자가 LLDB로 옮겨도 큰 학습 비용 없이 적응 가능.

#어느 것을 쓸까

플랫폼이 가장 중요한 결정 요인.

• Linux: GDB. 모든 배포판에 기본 설치. 대부분의 도구가 GDB와 통합 (perf, valgrind —vgdb 등).
• macOS (Apple Silicon): LLDB. Xcode와 같이 설치. 공식 지원되는 유일한 디버거.
• 임베디드/크로스 컴파일: GDB. gdb-multiarch로 다양한 아키텍처 지원.
• iOS / Swift: LLDB. Apple이 만든 거라 통합 최강.

크로스 플랫폼 코드에서는 둘 다 알아 두는 게 좋습니다. 이 시리즈는 두 도구 병행 학습으로 진행합니다 — 명령어를 GDB/LLDB 양쪽으로 같이 보여 줍니다.

#설치

#Linux (Debian/Ubuntu)

1
sudo apt update
2
sudo apt install gdb        # GDB
3
sudo apt install lldb       # LLDB (선택)

#Linux (Fedora/RHEL)

1
sudo dnf install gdb
2
sudo dnf install lldb

#macOS

1
# LLDB — Xcode Command Line Tools에 포함
2
xcode-select --install
3

4
# GDB — 별도 설치, 더 복잡 (코드 사이닝 필요)
5
brew install gdb

macOS에서 GDB를 쓰려면 코드 사이닝이 필요합니다. Apple의 보안 정책이 디버거 권한을 제한하기 때문. Homebrew brew 설치 후:

1
# 사이닝 (LLDB는 자동, GDB만 수동)
2
# 자세한 절차는 https://sourceware.org/gdb/wiki/PermissionsDarwin

복잡합니다. macOS는 LLDB가 사실상 답.

#크로스 컴파일

1
# ARM 타겟
2
sudo apt install gdb-multiarch
3

4
# 사용
5
gdb-multiarch ./arm-binary
6
(gdb) set architecture arm
7
(gdb) target remote :1234   # gdbserver 연결

Ch 8: Remote Debugging에서 자세히.

#버전 확인

1
$ gdb --version
2
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
3

4
$ lldb --version
5
lldb version 15.0.7

*GDB 10+, LLDB 13+*가 권장. 이전 버전은 현대 컴파일러의 디버그 정보 (DWARF 5)를 못 읽을 수 있음.

#컴파일러 옵션 — 디버그 정보를 위한 준비

디버거가 변수 이름·줄 번호·타입 정보를 보려면 디버그 심볼이 필요합니다.

1
gcc -g -O0 -fno-omit-frame-pointer main.c -o myapp

각 옵션:

• -g — DWARF 디버그 정보 생성. 변수, 함수, 타입, 줄 번호 모두 포함. 필수.
• -O0 — 최적화 없음. 컴파일러가 코드를 변형하지 않아 소스 그대로 추적 가능.
• -fno-omit-frame-pointer — 스택 프레임 포인터 유지. backtrace 정확도.

#최적화 레벨과 디버깅

1
gcc -g -O0 myapp.c    # 디버깅 친화적. 가장 권장.
2
gcc -g -O1 myapp.c    # 일부 최적화. 보통 디버깅 가능.
3
gcc -g -O2 myapp.c    # 인라인 많음. 변수 사라짐.
4
gcc -g -Og myapp.c    # 디버깅용 최적화. GCC 4.8+ 권장.

**-Og**는 디버깅을 깨지 않는 선에서 최적화합니다. 릴리스에 가까운 행동을 디버깅하고 싶을 때 좋습니다.

-O2에서는 변수가 레지스터에 살아 사라지거나, 루프가 합쳐지거나, 조건문이 통째로 사라질 수 있습니다. 디버거에서 print x했을 때 <optimized out> 메시지를 만나면 그 자리.

#디버그 심볼 분리

릴리스 바이너리에는 디버그 심볼을 제거하지만, 나중에 디버깅용으로 따로 보관합니다.

1
# 1. 디버그 빌드
2
gcc -g -O2 main.c -o myapp
3

4
# 2. 심볼만 추출
5
objcopy --only-keep-debug myapp myapp.debug
6

7
# 3. 본 바이너리에서 제거
8
strip myapp
9

10
# 4. 심볼 위치 link
11
objcopy --add-gnu-debuglink=myapp.debug myapp

배포는 myapp (작음), 서버 충돌 시는 myapp.debug로 symbol 매칭. Linux 배포판이 -dbgsym 패키지로 분리 제공하는 게 이 방식.

#첫 세션 — 간단한 프로그램 디버깅

1
#include <stdio.h>
2

3
int factorial(int n) {
4
    if (n <= 1) return 1;
5
    return n * factorial(n - 1);
6
}
7

8
int main() {
9
    int n = 5;
10
    int result = factorial(n);
11
    printf("%d! = %d\n", n, result);
12
    return 0;
13
}

1
$ gcc -g -O0 hello.c -o hello

#GDB 세션

1
$ gdb ./hello
2
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
3
...
4
Reading symbols from ./hello...
5

6
(gdb) break main
7
Breakpoint 1 at 0x114e: file hello.c, line 8.
8

9
(gdb) run
10
Starting program: /tmp/hello
11
Breakpoint 1, main () at hello.c:8
12
8       int n = 5;
13

14
(gdb) next
15
9       int result = factorial(n);
16

17
(gdb) print n
18
$1 = 5
19

20
(gdb) step
21
factorial (n=5) at hello.c:4
22
4       if (n <= 1) return 1;
23

24
(gdb) backtrace
25
#0  factorial (n=5) at hello.c:4
26
#1  0x000055555555515f in main () at hello.c:9
27

28
(gdb) finish
29
Run till exit from #0  factorial (n=5) at hello.c:4
30
0x000055555555515f in main () at hello.c:9
31
9       int result = factorial(n);
32
Value returned is $2 = 120
33

34
(gdb) continue
35
Continuing.
36
5! = 120
37
[Inferior 1 (process 12345) exited normally]
38

39
(gdb) quit

#LLDB 세션

1
$ lldb ./hello
2
(lldb) target create "./hello"
3
Current executable set to '/tmp/hello' (x86_64).
4

5
(lldb) breakpoint set --name main
6
Breakpoint 1: where = hello`main + 4 at hello.c:8, address = 0x114e
7

8
(lldb) run
9
Process 12345 launched: '/tmp/hello' (x86_64)
10
Process 12345 stopped
11
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
12
    frame #0: 0x55555555514e hello`main at hello.c:8
13
   5      }
14
   6
15
   7      int main() {
16
-> 8          int n = 5;
17
   9          int result = factorial(n);
18

19
(lldb) next
20
* thread #1, stop reason = step over
21
    frame #0: hello`main at hello.c:9
22

23
(lldb) print n
24
(int) $0 = 5
25

26
(lldb) step
27
* thread #1, stop reason = step in
28
    frame #0: hello`factorial(n=5) at hello.c:4
29

30
(lldb) bt
31
* thread #1, queue = 'com.apple.main-thread'
32
  * frame #0: hello`factorial(n=5) at hello.c:4
33
    frame #1: hello`main at hello.c:9
34

35
(lldb) finish
36
* thread #1, stop reason = step out
37
    frame #0: hello`main at hello.c:9
38
Return value: (int) $1 = 120
39

40
(lldb) continue
41
Process 12345 resuming
42
5! = 120
43
Process 12345 exited with status = 0
44

45
(lldb) quit

같은 시나리오를 두 디버거로 따라갔습니다. 명령은 거의 동일하고, 출력 형식만 조금 다릅니다.

#자주 만나는 첫 문제

#”No symbol table is loaded”

1
(gdb) break main
2
No symbol table is loaded.  Use the "file" command.

원인: -g 옵션 없이 컴파일.

해결:

1
gcc -g hello.c -o hello

#“Cannot find bounds of current function”

원인: 디버그 정보 부분 손상 또는 -O2 이상에서 함수 인라인.

해결: -O0 또는 -Og로 재컴파일.

#macOS GDB의 “unable to find Mach task port”

1
$ gdb ./hello
2
(gdb) run
3
Unable to find Mach task port for process-id...

원인: macOS 코드 사이닝 누락.

해결: 위에서 본 GDB 사이닝 절차. 또는 LLDB로 전환.

#”Operation not permitted”

1
$ gdb -p 12345
2
ptrace: Operation not permitted.

원인: Linux의 ptrace_scope 보안 설정.

해결:

1
# 임시
2
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
3

4
# 영구 (root 권한 필요)
5
echo 'kernel.yama.ptrace_scope = 0' | sudo tee -a /etc/sysctl.conf

#시리즈 로드맵

#정리

• 디버거는 프로그램을 멈추고 조사하는 도구. ptrace(Linux) / Mach(macOS) 기반.
• GDB는 Linux/Unix, LLDB는 macOS/iOS 주력. 명령은 거의 동일.
• 컴파일: -g(디버그 심볼) + -O0 또는 -Og(디버깅 친화 최적화).
• 첫 세션: break main → run → next / step → print → bt → continue.
• macOS에서 GDB는 복잡 — LLDB 권장.

#다음 장 예고

Ch 2: 기본 명령에서는 디버거에서 매일 쓰는 명령 10개를 자세히 다룹니다. break의 다양한 형태, step vs next vs finish 차이, print 포맷.

#참고 자료

• GDB Documentation
• LLDB Tutorial
• GDB to LLDB Command Map — 명령 대조표
• DWARF Debugging Standard