[Trace32] Call Stack 제대로 읽는 방법 (실제 흐름으로 이해하기)

디버깅을 하다 보면 어느 순간부터 막히는 지점이 생긴다.

 

코드는 멈췄고, 변수 값도 확인했다.

겉으로 보기에는 모든 준비가 끝난 상태다.

 

그런데도 문제의 원인을 찾지 못한다.

 

이 상황에서 대부분은 현재 함수 안에서 계속 Step을 누르면서

값이 어떻게 바뀌는지만 반복해서 확인한다.

 

하지만 이 방식으로는 해결되지 않는 경우가 많다.

 

왜냐하면 문제는 대부분 “지금 보고 있는 함수”가 아니라 그 이전 흐름에서 이미 만들어져 있기 때문이다.

 

실제 Trace32 Call Stack을 보면

 

이걸 이해하기 위해 실제 Trace32 Call Stack을 하나 보자.

 

처음 보면 단순히 함수 이름이 나열된 것처럼 보인다.

그래서 많은 경우 위에서부터 읽기 시작한다.

 

하지만 그렇게 보면 아무것도 이해되지 않는다.

Call Stack은 보는 방향이 다르기 때문이다.

 

Call Stack은 "아래에서 위로" 읽는다

 

이 구조는 위에서 아래로 읽는 것이 아니라, 아래에서 위로 올라가면서 읽어야 한다.

 

가장 아래에 있는 부분은 프로그램이 시작된 흐름이다.

여기서는 OS가 Task를 실행하는 지점이다.

 

그 위로 올라가면 해당 Task 안에서 RTE가 Runnable을 호출하고,

그 Runnable이 다시 Application 함수(RE_ABS_MAIN)를 호출한다.

 

그리고 가장 위에 있는 함수가 지금 CPU가 실제로 실행을 멈춘 위치다.

 

흐름으로 연결하면 이렇게 된다

 

 

이걸 하나의 흐름으로 이어서 보면 이렇게 된다.

OS가 10ms Task를 실행하고,
그 안에서 RTE가 Runnable을 호출하고,
그 Runnable이 RE_ABS_MAIN을 호출했고,
지금은 그 함수 내부에서 멈춰 있는 상태다.

 

여기서 중요한 건 하나다.

지금 보고 있는 RE_ABS_MAIN은 시작점이 아니라

이미 여러 단계를 거쳐서 도달한 “결과 위치”라는 점이다.

 

왜 현재 함수만 보면 안 되는가

 

이걸 모르면 어떻게 되냐면, 현재 함수 안에서만 계속 분석하게 된다.

 

예를 들어 ABS_Array_CB 값이 이상하다고 가정해보자.

 

대부분은 이 값을 기준으로 조건문을 확인하고, 왜 이 값이 이런지 이 함수 안에서만 계속 본다.

하지만 이 값은 여기서 생성된 것이 아니라 위쪽 흐름에서 전달된 값일 가능성이 훨씬 높다.

 

이때 Call Stack을 보면 판단이 바뀐다.

 

“여기서 만든 값이 아니라면, 위에서 내려온 값이다”

이 순간부터 디버깅 방향이 달라진다.

 

현재 함수에서 계속 보는 것이 아니라, 한 단계 위 함수로 올라가야 한다는 판단이 생긴다.

 

실제로 디버깅은 이렇게 진행된다.

 

디버깅은 여기서 두 갈래로 나뉜다.

 

Call Stack을 보지 않으면 현재 위치에서 계속 Step을 반복하게 된다.

반대로 Call Stack을 보면 지금 위치가 아니라 “이전 흐름”을 보게 된다.

 

그래서 상위 함수로 이동해서 값이 어디서 들어왔는지 추적하게 된다.

 

이 차이는 단순한 방법 차이가 아니다.

디버깅을 “현재 상태 확인”으로 할 것인지,

아니면 “원인 추적”으로 할 것인지를 나누는 기준이다.

 

Call Stack을 이해하면 바뀌는 것

 

Call Stack을 이해하면 자연스럽게 이런 질문을 하게 된다.

 

- 이 함수는 어디서 호출됐는가?

- 왜 이 타이밍에 실행됐는가?

- 이 값은 어디서 들어온 것인가?

 

이 질문들이 나오기 시작하면 디버깅은 더 이상 막히지 않는다.

 

정리

 

Call Stack은 단순히 함수 목록을 보여주는 창이 아니다.

현재 코드가 여기까지 오게 된 전체 흐름을 보여주는 도구다.

 

이걸 기준으로 보면 지금 보고 있는 코드가 시작점인지, 아니면 결과인지 바로 구분할 수 있다.

한 줄로 정리하면 이렇다.

 

문제는 현재 위치에 있는 것이 아니라, 그 위 호출 흐름에 있다.