GDB·LLDB TUI와 프런트엔드 — gdb-dashboard·gef·pwndbg·VS Code

GDB는 기본적으로 명령줄입니다. 강력하지만 한 화면에 지금 어디서 멈췄는지, 변수가 얼마인지, 콜스택, 레지스터를 동시에 보여 주지 못합니다. 이 장은 TUI(터미널 UI)와 외부 프런트엔드로 그 한계를 메우는 방법입니다.

내장 TUI에서 출발해 cgdb·gdb-dashboard·gef/pwndbg 같은 터미널 확장, VSCode·nvim-dap·Emacs 같은 IDE 통합, 마지막으로 모든 IDE가 공유하는 DAP(Debug Adapter Protocol)의 정체까지 살펴봅니다.

#GDB 내장 TUI

1
(gdb) tui enable
2
(gdb) layout src         # 소스 + 명령
3
(gdb) layout asm         # 어셈블리 + 명령
4
(gdb) layout regs        # 레지스터 패널 추가
5
(gdb) layout split       # 소스 + 어셈블리 + 명령

토글 단축키 Ctrl-x a. 한 번 켜면 화면이 분할되어 위쪽엔 소스가, 아래쪽엔 명령창이 뜹니다. 화살표/PgUp으로 소스 스크롤, Ctrl-x o로 패널 포커스 전환, Ctrl-l로 다시 그리기.

#동작 원리

TUI는 ncurses 위에 구현됐습니다. 정지·재개 이벤트마다 GDB가 현재 PC·소스·레지스터를 다시 받아 화면을 그립니다.

레이아웃은 고정된 윈도 셋의 조합.

#자주 쓰는 단축키

#제약

• 윈도 깨짐이 자주 일어남(Ctrl-l 자주 누르게 됨). 이유는 GDB가 ncurses 화면 위에 그대로 print 출력을 던지면서 화면이 망가지기 때문입니다. Python으로 직접 ncurses와 통합한 cgdb·dashboard가 더 안정적인 이유.
• 마우스 안 됨.
• 일부 환경에서 color 안 나옴.
• 변수·watch 패널 없음.

가벼운 디버깅에는 충분. 큰 코드베이스에선 곧 한계를 느낍니다.

#cgdb — 분할 화면 GDB

cgdb는 위에 vi 키 바인딩이 적용된 소스 뷰어, 아래에 GDB 명령창이 있는 진짜 TUI.

1
$ cgdb ./my_program

• Esc로 소스 패널, i로 명령 패널.
• 소스 패널에서 vi 키(j/k//)로 이동.
• 마우스 휠 스크롤 가능.
• 색상·구문 강조가 깔끔.

#동작 원리

cgdb는 GDB를 서브프로세스로 띄우고 stdin/stdout을 가로챕니다. MI(머신 인터페이스) 명령을 보내 현재 PC, 소스 파일, 콜스택을 구조적으로 받아 자체 ncurses UI를 그립니다. GDB 내장 TUI보다 ncurses와 충돌이 적은 이유.

GDB 내장 TUI보다 훨씬 안정적입니다. 패키지 매니저로 바로 설치되므로 첫 선택지로 추천.

1
~/.cgdb/cgdbrc            # 설정
2
set winminheight=3
3
set winsplit=top_big
4
set syntax=on
5
set color=on
6
map <C-n> :gdb next<CR>

#gdb-dashboard — 깔끔한 단일 파이썬 스크립트

cyrus-and/gdb-dashboard — 한 파이썬 스크립트(~/.gdbinit에 source)로 콘솔에 멀티 패널을 그립니다.

1
$ wget -O ~/.gdbinit https://raw.githubusercontent.com/cyrus-and/gdb-dashboard/master/.gdbinit
2
$ gdb ./my_program

기본 패널: source / assembly / stack / registers / variables / breakpoints / expressions / threads / memory / history.

1
>>> dashboard -layout source assembly stack registers variables
2
>>> dashboard memory watch 0x7fff0000 64
3
>>> dashboard expressions watch "i + j"
4
>>> dashboard source -style compact
5
>>> dashboard -style syntax_highlighting 'monokai'

#어떻게 그리는가

gdb.events.stop에 훅을 걸어 정지마다 각 패널의 콘텐츠를 Python으로 수집해 print. ncurses를 쓰지 않으므로 화면 깨짐 없음. 매 정지마다 위에서 아래로 다시 그려지는 식이라 스크롤백을 잃지 않습니다.

장점 — Python 한 파일이라 설정/이식 쉬움. TUI 모드처럼 화면이 깨지지 않고, 매 정지마다 위쪽에 패널이 다시 그려집니다.

커스텀 모듈을 직접 추가할 수 있어 팀별 디버깅 환경을 표준화하기 좋습니다.

1
class MyPanel(Dashboard.Module):
2
    def label(self):
3
        return "my-counters"
4
    def lines(self, term_width, term_height, style_changed):
5
        cnt = int(gdb.parse_and_eval("g_counter"))
6
        return [f"counter = {cnt}"]

#gef / pwndbg / peda — 보안·exploit 디버깅

세 가지 모두 보안 분석가의 작업을 GDB 위에서 빠르게 하기 위한 Python 확장입니다. 설치하면 정지할 때마다 레지스터·스택·디스어셈블·코드 컨텍스트가 자동으로 한 화면에 뜹니다.

1
# gef
2
$ wget -O ~/.gdbinit-gef.py https://gef.blah.cat/py
3
$ echo "source ~/.gdbinit-gef.py" >> ~/.gdbinit
4

5
# pwndbg
6
$ git clone https://github.com/pwndbg/pwndbg
7
$ cd pwndbg && ./setup.sh

이 장의 관심사는 TUI이므로 여기서는 셋의 성격만 구분해 둡니다. gef는 한 파일짜리라 가볍고 ARM·MIPS·PPC까지 따라오며, pwndbg는 힙 분석이 가장 깊어 CTF·exploit에서 사실상 표준입니다. peda는 x86 중심의 오래된 도구라 지금은 옛 자료를 따라갈 때 씁니다.

셋의 상세 비교와 context·vmmap·heap·checksec 같은 공통 명령표는 GDB Extension and IDE Ch 6: GDB 프런트엔드 비교에 정리돼 있습니다.

주의할 점은 하나입니다. 이 확장들은 매 정지마다 큰 컨텍스트를 쏟아내기 때문에, 보안 분석이 아닌 일반 애플리케이션 디버깅에서는 화면이 오히려 시끄러워집니다. 그럴 때는 앞의 gdb-dashboard나 cgdb 쪽이 맞습니다.

#VSCode + cppdbg / CodeLLDB

터미널을 벗어나면 VSCode가 가장 많이 쓰는 프런트엔드입니다. GDB 사용자 입장에서 알아 둘 것은 두 익스텐션이 GDB와 대화하는 방식이 다르다는 점입니다.

cppdbg는 Microsoft가 만든 C/C++ 익스텐션으로, GDB와 MI 프로토콜로 통신합니다. GDB의 명령이 그대로 전달되므로 .gdbinit의 pretty-printer 설정이 살아 있고, setupCommands로 GDB 명령을 직접 밀어 넣을 수도 있습니다. CodeLLDB는 LLDB의 DAP 서버를 직접 띄우는 쪽이라 macOS·Rust·Swift에서 강합니다.

MI를 한 겹 거치기 때문에 생기는 어긋남도 있습니다. 조건부 breakpoint의 표현식이 GDB에서 직접 칠 때와 미묘하게 다르게 평가되는 경우가 있고, fork 추적은 GDB에서 set follow-fork-mode로 다루던 만큼 정교하지 않습니다. 콘솔 입력이 필요한 프로그램은 "externalConsole": true가 필요하고, core dump는 coreDumpPath를 따로 줘야 합니다.

launch.json 전체 예시(launch·attach·gdbserver 원격), 단축키표, Logpoint와 Watch 패널 사용법은 GDB Extension and IDE Ch 6에 정리돼 있습니다.

#Neovim — nvim-dap

nvim-dap이 Debug Adapter Protocol(DAP) 클라이언트, nvim-dap-ui가 UI. VSCode와 같은 디버그 어댑터(cppdbg, CodeLLDB)를 그대로 씁니다.

1
local dap = require('dap')
2

3
dap.adapters.lldb = {
4
  type = 'executable',
5
  command = '/usr/bin/lldb-vscode',
6
  name = 'lldb',
7
}
8

9
dap.configurations.cpp = {
10
  {
11
    name = 'Launch',
12
    type = 'lldb',
13
    request = 'launch',
14
    program = function()
15
      return vim.fn.input('Path to executable: ', vim.fn.getcwd() .. '/', 'file')
16
    end,
17
    cwd = '${workspaceFolder}',
18
    stopOnEntry = false,
19
    args = {},
20
  },
21
  {
22
    name = 'Attach to PID',
23
    type = 'lldb',
24
    request = 'attach',
25
    pid = require('dap.utils').pick_process,
26
    args = {},
27
  },
28
}
29

30
dap.configurations.c = dap.configurations.cpp
31
dap.configurations.rust = dap.configurations.cpp

1
vim.keymap.set('n', '<F5>', dap.continue)
2
vim.keymap.set('n', '<F10>', dap.step_over)
3
vim.keymap.set('n', '<F11>', dap.step_into)
4
vim.keymap.set('n', '<S-F11>', dap.step_out)
5
vim.keymap.set('n', '<F9>', dap.toggle_breakpoint)
6
vim.keymap.set('n', '<leader>B', function()
7
  dap.set_breakpoint(vim.fn.input('Condition: '))
8
end)
9
vim.keymap.set('n', '<leader>dl', dap.run_last)
10
vim.keymap.set('n', '<leader>dt', dap.terminate)

dap-ui가 VSCode와 거의 같은 패널 레이아웃을 그립니다.

1
local dapui = require('dapui')
2
dapui.setup()
3
dap.listeners.after.event_initialized['dapui_config'] = dapui.open
4
dap.listeners.before.event_terminated['dapui_config'] = dapui.close

Neovim 안에서 디버그 패널 띄우고, REPL로 표현식 평가. Vim 키를 유지하면서 IDE 수준의 경험을 가져갑니다.

#DAP — 표준 프로토콜의 의미

VSCode·Neovim·Emacs(dap-mode)·Sublime·Helix가 모두 같은 DAP를 씁니다. 따라서 한 어댑터(cppdbg)를 설치하면 어느 에디터든 동일한 디버깅 경험을 얻을 수 있습니다. RSP가 디버거 ↔ 타깃 표준이라면 DAP는 IDE ↔ 디버거 표준.

1
[에디터] ← DAP → [adapter (예: cppdbg)] ← MI → [GDB]
2
                                              ↑ RSP
3
                                            [gdbserver / OpenOCD]

#DAP 메시지

JSON-RPC over TCP/stdio. 모든 메시지가 request / response / event 셋.

1
// 요청
2
{"seq": 1, "type": "request", "command": "initialize",
3
 "arguments": {"clientID": "vscode", "linesStartAt1": true}}
4

5
// 응답
6
{"seq": 2, "type": "response", "request_seq": 1, "success": true,
7
 "command": "initialize",
8
 "body": {"supportsConfigurationDoneRequest": true, ...}}
9

10
// 이벤트
11
{"seq": 3, "type": "event", "event": "stopped",
12
 "body": {"reason": "breakpoint", "threadId": 1}}

주요 명령.

VSCode의 변수 트리는 재귀적인 variables 호출입니다. 사용자가 트리 노드를 펼칠 때마다 그 노드의 variablesReference를 인자로 다시 호출. 결과적으로 깊은 객체도 지연 로드되어 IDE가 빠릅니다.

#Emacs — dap-mode / gud

전통적으로 Emacs는 M-x gdb로 GUD(GDB UI mode)를 썼습니다. 요즘은 dap-mode로 같은 DAP 어댑터를 공유.

1
(use-package dap-mode
2
  :after lsp-mode
3
  :config (dap-auto-configure-mode))
4

5
(use-package dap-cpptools)        ; cppdbg
6
(use-package dap-lldb)

1
(dap-register-debug-template
2
 "C++ Launch"
3
 (list :type "cppdbg"
4
       :request "launch"
5
       :name "C++ Launch"
6
       :MIMode "gdb"
7
       :program "${workspaceFolder}/build/my_program"
8
       :cwd "${workspaceFolder}"))

자세한 설정은 dap-mode 문서. Doom Emacs는 lsp +debugger 모듈로 한 번에.

#데이터·메모리 시각화

• VSCode의 Hex Editor + memoryview — 메모리 영역을 hex 그리드로.
• gef의 memoryview — 메모리 영역을 색칠해 표시.
• gdb의 dashboard memory — 직접 watch 영역 지정.
• GDB 자체 — x/100bx 0x... 또는 Python으로 binary blob 시각화.

큰 버퍼·이미지 디버깅에서는 hex 뷰가 콜스택보다 더 자주 쓰입니다.

#NumPy/이미지 자체 시각화

GDB Python으로 NumPy 배열을 PNG로 떨어뜨려 외부 뷰어로 보기.

1
class ViewImage(gdb.Command):
2
    def __init__(self):
3
        super().__init__("view_image", gdb.COMMAND_USER)
4
    def invoke(self, arg, from_tty):
5
        v = gdb.parse_and_eval(arg)
6
        w = int(v['width']); h = int(v['height'])
7
        data = v['data']
8
        # 메모리를 numpy로
9
        import numpy as np
10
        buf = gdb.selected_inferior().read_memory(int(data), w*h*3)
11
        arr = np.frombuffer(buf, dtype=np.uint8).reshape((h, w, 3))
12
        from PIL import Image
13
        Image.fromarray(arr).save('/tmp/view.png')
14
        import subprocess
15
        subprocess.Popen(['xdg-open', '/tmp/view.png'])
16

17
ViewImage()

컴퓨터 비전·비디오 코덱·머신러닝 디버깅에서 가시화는 콜스택을 100번 들여다보는 것보다 빠릅니다.

#Cortex-Debug — Cortex-M을 붙일 때

Cortex-M 펌웨어라면 Cortex-Debug가 IDE 쪽 표준입니다. OpenOCD·J-Link·ST-Link·Black Magic Probe를 자동으로 띄우고 GDB를 붙여 주므로, Ch 8에서 손으로 하던 gdbserver 연결이 설정 한 덩어리로 줄어듭니다.

이 시리즈의 관심사는 GDB 쪽이므로 여기서는 GDB 사용자가 얻는 것만 짚습니다. SVD 파일을 읽어 peripheral 레지스터를 비트 단위로 펼쳐 주고, Segger RTT 출력을 콘솔에 얹어 주며, J-Link에서는 CPU를 세우지 않고도 변수를 갱신합니다.

launch.json 전체 예시와 servertype별 차이는 GDB Extension and IDE Ch 6에 있습니다.

#어느 걸 골라야 하나

#정리

• 내장 TUI(Ctrl-x a)는 빠른 시각화, 화면 깨짐만 감수하면 충분.
• cgdb·gdb-dashboard가 터미널에서 가장 안정적.
• gef/pwndbg는 보안·CTF 용으로 강력하지만 일반 작업엔 시끄러움.
• IDE 통합은 VSCode + cppdbg/CodeLLDB 또는 nvim-dap.
• DAP가 IDE↔디버거 표준 — request/response/event 셋의 JSON-RPC.
• 변수 트리는 variables 재귀 호출로 지연 로드.
• Cortex-M은 VSCode Cortex-Debug 익스텐션이 자동으로 OpenOCD/J-Link까지 묶어 줌. SVD/RTT 통합.

#다음 장 예고

Ch 11(시리즈 마지막) — 실전 팁. STL pretty-printer, -O2로 빌드된 코드 디버깅, .gdbinit 추천 설정, time-travel(rr)으로 마무리.

#관련 항목

• Ch 8: 원격 디버깅 — Cortex-Debug 익스텐션이 OpenOCD를 띄움
• Ch 9: Python 스크립팅 — dashboard도 Python 확장
• DAP 명세
• cgdb 공식
• gdb-dashboard
• pwndbg
• Cortex-Debug
• nvim-dap