시간여행 디버거 rr와의 기나긴 여정
안녕하세요. 이번 글에서는 제가 시간여행 디버거인 rr를 사용하면서 겪었던 우여곡절 가득한 이야기를 공유하고자 합니다. 최신 Intel 아키텍처부터 AMD 노트북, 그리고 WSL까지, 다양한 환경에서 rr을 사용해 본 경험을 바탕으로 해결책을 찾아가는 과정을 담아보았습니다.
1. 시간여행 디버거 rr와의 첫 만남
업무상 c/cpp 코드를 많이 컴파일하면서 gdb, cgdb, vscode debugger등을 많이 사용하는데, 디버거에 시간을 많이 쏟다 보니, 시간여행으로 유명한 rr 디버거를 한번 사용해 보고 싶었습니다. 과거로 돌아가면서 디버깅할 수 있다는 점이 매력적이었고, 실제로 사용해 보니 생산성이 크게 향상되었습니다.
그러나, 제 최신 Meteor Lake 노트북에서는 rr이 정상 작동하지 않았습니다. 문제를 파악해보니, rr이 Meteor Lake 아키텍처를 지원하지 않았던 것이 원인이었습니다. 저는 직접 이슈를 올려 패치가 적용되도록 했습니다. (사실 Meteor Lake에서 rr이 돌아가는 건 제 덕분입니다! 😎)
하지만, 패치가 적용된 후에도 여전히 작동하지 않았습니다. 그 이유는 제가 WSL (Windows Subsystem for Linux)을 사용하고 있었기 때문입니다.
2. WSL의 장벽: perf stat br 문제
25년 3월 기준 WSL은 5.15 커널까지만 Microsoft가 지원하고 있습니다. 이 버전에서는 Meteor Lake 아키텍처에서 perf가 정상 작동하지 않습니다.
따로 공을 들여 WSL Kernel 소스를 받아 perf를 컴파일해야 합니다.
https://github.com/microsoft/WSL2-Linux-Kernel
위 레포를 받아서 열심히 perf를 컴파일해줬습니다. 혹시 몰라 커널도 한번 컴파일해봤습니다. 한 3시간 정도 걸리더군요...
그럼에도 불구하고 아래 명령어가 동작하지 않았습니다.
$ perf stat -e br_inst_retired.cond truerr debugger가 동작하기 위해서는 위 perf 기능이 존재해야 하는데, Meteor Lake는 최신 커널에서만 지원합니다.
WSL는 지원하는 커널 버전이 낮기 때문에 이를 해결할 방법이 없었습니다. 구형 CPU를 가진 오래된 노트북에서는 WSL에서도 rr 디버거가 잘 작동했지만, 너무 느려서 실사용이 어려웠습니다.
3. 개발 서버의 문제: 구형 커널의 한계
업무용 노트북에서의 시도를 포기하고, 개발 서버에서 rr을 사용해 보려고 했습니다. 그러나, 개발 서버의 커널 버전은 4.7 이하였고, 이 버전에서는 rr이 동작하지 않았습니다.
이로 인해 rr 사용은 또다시 실패로 돌아갔습니다.
4. AMD 노트북의 함정: Zen 아키텍처 문제
할 수 없이 보조용 AMD 노트북을 구입했습니다. 그런데, AMD의 Zen 아키텍처에서는 SpecLockMap 최적화가 문제가 되었습니다. rr 사용 시 아래와 같은 안내가 떴습니다.
On Zen CPUs, rr will not work reliably unless you disable the hardware SpecLockMap optimization.이를 해결하기 위해 scripts/zen_workaround.py 스크립트를 실행해 보았지만, 가끔 작동하고 가끔 작동하지 않는 이상한 현상이 나타났습니다. 게다가 성능이 매우 느렸습니다.
5. 다시 Intel 노트북: Meteor Lake와의 전투
결국 Intel 노트북을 다시 구입했습니다. 이번에도 Meteor Lake 아키텍처였습니다. 다행히 최신 Arch Linux와 6.12 커널을 사용해 rr이 잘 동작할 것이라고 확신했습니다.
그런데, Arch Linux에서는 rr 디버거를 빌드하는 방법에 대한 안내가 없었습니다. 많은 시도 끝에 결국 빌드에 성공했고, 성공 기념으로 이슈에 자랑도 했습니다.
처음 실행했을 때는 기쁘게도 잘 동작했습니다. 하지만 기쁨도 잠시, 다시 실행하니 랜덤하게 동작하지 않는 문제가 발생했습니다.
6. 성능 코어와 효율 코어의 이슈
Hybrid Core... 쓰지 마세요...
문제를 파고들어 보니, Intel Meteo Lake 아키텍처는 perf core와 efficient core가 나누어져 있었고, efficient core에서는 rr이 정상 동작하지 않는다는 것을 알게 되었습니다.
해결 방안: taskset을 이용한 CPU Affinity 고정
이 문제를 해결하기 위해 taskset 명령어를 사용해 CPU affinity를 고정시켜 보았습니다. 제 노트북은 총 18개의 코어 중 8개가 Performance Thread, 10개가 Efficient Core였기 때문에 아래와 같이 명령어를 실행했습니다.
taskset -c 0,1,2,3,4,5,6,7 rr record a.out이 방법으로 마침내 rr이 정상적으로 작동했습니다. 그 순간의 감격은 이루 말할 수 없었습니다.
7. 마무리하며: rr와의 전쟁의 끝?
커널이 업데이트되거나, rr이 업데이트되거나, Intel이 좀 더 나은 CPU를 출시하거나 하지 않는 이상 rr이 모든 환경에서 완벽하게 동작하긴 어려울 것입니다.
하지만, taskset을 이용한 CPU affinity 고정 방법으로 현재로서는 임시방편으로 문제를 해결했기에, 이를 바탕으로 안정적으로 rr을 사용할 수 있게 되었습니다.
이번 글이 rr을 사용하고자 하시는 분들께 작은 도움이 되기를 바랍니다. 긴 글 읽어주셔서 감사합니다! 😊
