스택 오버플로 디버깅 MCU: 맵 파일 분석과 스택 크기 산정 공식

임베디드 펌웨어 개발 현장에서 원인을 알 수 없는 간헐적 시스템 리셋이나 메모리 오염 현상은 대부분 스택 메모리 경계 침범에서 기인합니다. 특히 SRAM 용량이 수십 킬로바이트 수준으로 제한된 마이크로컨트롤러 환경에서는 스택 오버플로 디버깅 MCU 작업이 시스템 안정성을 확보하는 결정적인 분수령이 됩니다. 컴파일 시점에는 에러 없이 빌드되더라도 런타임에 깊은 호출 체인이나 중첩 인터럽트가 맞물리면 예외 없이 크래시로 이어집니다.

단순히 감에 의존하여 링커의 스택 크기를 임의로 늘리는 방식은 전역 변수나 힙(Heap) 영역을 압박하여 또 다른 메모리 고갈 문제를 야기합니다. 하향식 스택 아키텍처의 동작 원리와 맵 파일(Map File) 심볼 배치 구조를 명확히 이해해야만 근본적인 결함을 추적할 수 있습니다. 시스템이 HardFault 루프에 빠지는 원인을 분석하고, 컴파일러 진단 도구와 수학적 산출 공식을 결합하여 최적의 스택 크기를 결정해야 합니다.

MCU 스택 아키텍처와 오버플로 발생 메커니즘

하향식 스택 구조와 MSP 및 PSP 듀얼 스택 모드

ARM Cortex-M이나 RISC-V와 같은 주요 임베디드 코어는 일반적으로 하향식 완전 스택(Full-Descending Stack) 구조를 채택합니다. 스택 포인터(SP)는 RAM의 상위 주소인 _estack에서 출발하여 함수 진입 시 로컬 변수와 반환 주소를 저장하며 하위 주소 방향으로 이동합니다. 이때 할당된 스택 하한선(_stack_limit)을 초과하면 인접한 힙 영역이나 전역 변수(.bss, .data)가 할당된 메모리 블록을 덮어쓰게 됩니다.

특히 ARM Cortex-M 아키텍처는 하드웨어 수준에서 두 개의 독립된 스택 포인터를 지원합니다. 부팅 및 예외 처리를 담당하는 메인 스택 포인터(MSP)와 RTOS 태스크 컨텍스트에서 사용하는 프로세스 스택 포인터(PSP)입니다. 태스크 실행 중 인터럽트가 발생하면 하드웨어는 즉시 MSP로 전환하여 컨텍스트를 저장합니다. 따라서 개별 태스크의 PSP 고갈뿐만 아니라 중첩 인터럽트 누적으로 인한 MSP 고갈 여부도 함께 추적해야 합니다.

“Cortex-M 프로세서는 예외 발생 시 R0-R3, R12, LR, PC, xPSR을 포함하는 8워드(32바이트) 스택 프레임을 현재 활성 스택에 자동으로 푸시하며, 부동 소수점 확장(FPU) 활성화 시 추가 18워드가 누적되어 총 108바이트를 즉시 소비합니다.”
— Arm Developer: Cortex-M33 Devices Generic User Guide

스택 오버플로 디버깅 MCU: 맵 파일 및 링커 스크립트 분석

링커 스크립트 메모리 배치와 맵 파일 심볼 추적

빌드 산출물로 생성되는 링커 스크립트(.ld)와 맵 파일(.map)은 메모리 충돌 지점을 추적하는 핵심 기준점입니다. 링커 스크립트 내부에서 _Min_Stack_Size와 _Min_Heap_Size가 RAM 영역에 어떻게 배치되는지 명확히 파악해야 합니다. 스택 시작 위치와 전역 심볼 경계의 상대적 오프셋을 확인하는 과정이 선행되어야 합니다.

GCC 기반 툴체인에서는 메모리 맵과 심볼 크로스 레퍼런스를 출력하기 위해 전용 링커 플래그를 활성화해야 합니다. 다음은 맵 파일 생성과 메모리 할당 상태를 점검하는 빌드 옵션 구성입니다.

# GNU Toolchain 맵 파일 생성 및 메모리 요약 출력 플래그
arm-none-eabi-gcc -O2 -g -Wl,-Map=firmware_output.map,--cref,--print-memory-usage main.o system.o -T linker_script.ld -o firmware.elf

# 맵 파일 내 스택 경계 및 전역 변수 종료 심볼 탐색 명령어
grep -E "(_estack|__StackLimit|__bss_end__|_end)" firmware_output.map

출력된 맵 파일에서 __StackLimit(스택 하한선) 주소와 __bss_end__(초기화되지 않은 전역 변수 끝점) 주소를 비교 분석합니다. 하향식 스택에서 스택 포인터가 __StackLimit보다 낮아지면 전역 변수 영역을 침범하게 됩니다. --print-memory-usage 옵션은 RAM의 전체 점유율을 백분율로 요약하여 정적 데이터와 예약된 스택의 전체적인 균형을 검증할 수 있도록 돕습니다.

컴파일러 공식 옵션을 활용한 정적·동적 분석

GCC 스택 사용량 분석 옵션 및 프레임 진단 플래그

컴파일 타임에 함수별 스택 소비량을 측정하면 잠재적 위험 함수를 사전에 필터링할 수 있습니다. GCC와 Clang 컴파일러는 각 소스 파일 단위로 함수별 프레임 크기를 계산하는 -fstack-usage 옵션을 기본 제공합니다. 이 옵션은 빌드 시 소스 파일마다 .su 확장자를 가진 텍스트 리포트를 생성합니다.

# 함수별 스택 소비량 출력 및 임계치 초과 경고 설정
arm-none-eabi-gcc -c -fstack-usage -Wstack-usage=512 -fstack-protector-strong main.c -o main.o

# 생성된 main.su 파일 확인 결과 예시
# main.c:32:6:SystemInit	16	static
# main.c:54:5:ProcessBuffer	640	dynamic
# main.c:89:5:SensorTask	48	bounded

출력 태그 중 static은 고정 크기 프레임을 의미하며 최적화 예측이 가능합니다. 반면 dynamic은 가변 길이 배열(VLA)이나 alloca() 호출로 인해 런타임에 동적으로 크기가 결정되는 상태를 나타내므로 즉시 리팩터링해야 합니다. -Wstack-usage 플래그는 단일 함수가 특정 바이트(예: 512바이트)를 초과할 경우 컴파일러 경고를 발생시켜 대용량 버퍼가 로컬 스택에 선언되는 실수를 원천 차단합니다.

하드웨어 한계 레지스터 및 런타임 감지 기법 비교

Armv8-M 하드웨어 한계 레지스터와 MPU 가드 기법 비교

Armv8-M 메인라인 아키텍처(Cortex-M33, Cortex-M55 등)는 하드웨어 수준에서 스택 경계를 감시하는 MSPLIM 및 PSPLIM 레지스터를 지원합니다. 스택 포인터 레지스터가 이 기준치 이하로 떨어지는 순간 하드웨어 쓰기가 차단되고 즉시 UsageFault(STKOF)가 트리거됩니다. 반면 구형 Armv7-M(Cortex-M4 등) 코어에서는 MPU 가드 영역이나 소프트웨어 워터마킹에 의존해야 합니다.

최악 조건 스택 분석(WCSA) 기반 크기 산정 공식

콜 트리 분석과 안전 마진을 결합한 스택 계산식

스택 크기를 결정할 때는 단순한 추측 대신 최악 조건 스택 분석(Worst-Case Stack Analysis, WCSA) 공식을 적용해야 합니다. 단일 태스크의 실행 흐름에서 호출 깊이가 가장 깊은 콜 트리(Call Tree)의 총 스택 소비량을 합산하고, AAPCS 규격에 따른 8바이트 정렬 마진과 안전 계수를 곱하여 산정합니다.

FreeRTOS 환경에서 xTaskCreate()를 호출할 때 전달하는 스택 파라미터는 바이트(Byte)가 아니라 StackType_t 단위입니다. 32비트 MCU에서는 1개 단위가 4바이트(Word)를 의미합니다. 만약 1024바이트를 의도하고 인자값으로 1024를 전달하면 실제로는 4096바이트가 할당됩니다. 반대로 256을 전달해야 할 자리에 64를 입력하면 심각한 과소 할당으로 즉각적인 오버플로가 발생하므로 주의가 필요합니다.

실무 FAQ

기술 참고자료

공식 아키텍처 및 툴체인 기술 문서

• Arm Developer: Arm Compiler for Embedded User Guide – Stack use in C and C++
• Texas Instruments: tiarmclang Compiler User Manual – Setting the Size of the Stack and Heap Sections
• Arm Developer: Cortex-M33 Devices Generic User Guide