IAR Embedded Workbench for RX 로 프로그램의 스택 사용량 확인
IAR Embedded Workbench for RX 버전 2.60에는 스택 사용 분석이 도입되었습니다. 이 기사에서는 이 기능을 살펴보고 구축 시 애플리케이션의 최대 스택 사용량을 계산하고 런타임에 스택 포인터의 기호를 추적하는 몇 가지 기술을 소개합니다.
배경
스택은 연속 메모리의 고정 블록이며 개발자에 의해 정적으로 할당되어야 합니다. 여기에는 다음과 같은 C/C++ 기능에 대한 로컬 데이터가 포함되어 있습니다.
- 레지스터에 저장되지 않은 로컬 변수
- 레지스터에 저장되지 않은 함수 매개 변수
- 식의 임시 결과입니다.
- 함수의 반환 값( 레지스터를 통해 전달되지 않는 경우)
- 인터럽트 내용
- 함수가 반환되기 전에 복원해야 하는 프로세서 레지스터
스택은 두 부분으로 나눌 수 있습니다. 첫 번째 부분에는 기능에 사용되는 할당된 메모리가 있고 두 번째 부분에는 할당할 수 있는 사용 가능한 메모리가 포함되어 있습니다. 이들 사이의 경계는 스택의 상단이라고 하며, 일반적으로 전용 프로세서 레지스터인 스택 포인터(SP)로 표시됩니다. 메모리는 SP를 이동하여 스택에서 할당됩니다. 스택에 할당된 메모리는 함수가 반환될 때 해제되므로 이후 저장해야 하는 데이터를 저장할 수 없습니다.
스택의 주요 장점은 애플리케이션의 여러 부분에 있는 기능이 동일한 메모리 공간을 공유하여 데이터를 저장할 수 있다는 것입니다. 힙과 달리 스택은 조각화되거나 메모리 누수가 발생하지 않습니다.
적절한 스택 구성은 시스템 안정성과 신뢰성을 위해 필수적입니다. 스택 크기가 너무 작으면 SP가 스택 영역 밖으로 이동되어 오버플로 상황이 발생할 수 있습니다. 이 경우, 실행 코드는 스택 아래에 할당된 영역에 쓰여질 수 있으며(스택이 아래쪽으로 커질 경우), 덮어쓰기 변수, 와일드 포인터, 손상된 반환 주소 등과 같은 심각한 런타임 실패를 초래할 수 있습니다. 반면에 스택 크기를 너무 크게 설정하면 MCU 기반 임베디드 시스템에서는 RAM 리소스가 매우 제한될 수 있습니다.
정적 스택 사용량 분석
적절한 상황에서 링크는 각 호출 그래프 루트(다른 함수에서 호출되지 않은 함수)의 최대 스택 사용량을 정확하게 계산할 수 있습니다. 스택 사용 챕터가 링크 맵 파일에 추가되며, 각 호출 그래프 루트에 대한 가장 깊은 호출 체인 깊이와 각 호출 그래프 루트 범주에 대한 가장 깊은 호출 체인 깊이의 합이 나열됩니다. 계산은 애플리케이션의 각 기능에 대한 충분한 스택 사용 정보가 있는 경우에만 정확합니다.
일반적으로 컴파일러는 각 기능에 대해 이 정보를 생성합니다. 그러나 경우에 따라 개발자가 간접 호출(함수 포인터를 사용한 호출) 또는 재귀 함수에 대한 최대 반복 횟수를 컴파일러에 알리기 위해 추가 지시문을 제공해야 합니다. 이는 원본 코드에서 #pragma 지시문을 사용하거나 프로젝트 옵션 대화 상자에서 별도의 스택 사용량 제어 파일을 지정하여 수행할 수 있습니다.
스택 사용량 분석을 사용하도록 활성화
Advanced 탭의 Linker 옵션에서, Enable stack usage analysis를 체크:
또한 링크 맵 파일에는 스택 사용량 분석 결과가 포함되어 있으므로 반드시 생성하십시오. 링크 옵션의 목록 탭에서 활성화할 수 있습니다.
단순한 애플리케이션의 경우 스택 사용량 분석 결과는 단순하고 이해하기 쉽습니다. 일반적으로 프로그램 항목과 인터럽트 핸들러는 다른 함수에 의해 호출되지 않으므로 호출 그래프 루트로 간주됩니다. 아래 예에서 최대 스택 깊이는 프로그램 항목 호출 그래프 루트 범주(__iar_program_start)의 경우 288바이트이고 인터럽트 호출 그래프 루트 범주(__interrupt_170 및 _default_handler)의 경우 총 120바이트입니다.
*************************************************************************
*** STACK USAGE
***
Call Graph Root Category Max Use Total Use
------------------------ ------- ---------
interrupt 120 120
Program entry 288 288
Program entry
"__iar_program_start": 0xffffb14c
Maximum call chain 288 bytes
"__iar_program_start" 4
"_main" 8
"_printf" 8
"__PrintfFullNoMb" 152
"__LdtobFullNoMb" in xprintffull_nomb.o [4] 80
"__GenldFullNoMb" in xprintffull_nomb.o [4] 36
interrupt
"__interrupt_170": 0xffffaa22
Maximum call chain 52 bytes
"__interrupt_170" 52
interrupt
"_default_handler": 0xffff98cb
Maximum call chain 68 bytes
"_default_handler" 52
"_abort" 4
"__exit" 12간접 호출을 지정
간접 호출은 함수 포인터를 통해 함수를 호출하는 것을 의미합니다. 빌드 시 호출 기능을 알 수 없으므로, 링크는 간접 호출에 대한 스택 사용 정보를 자동으로 검색할 수 없습니다. 다음과 같은 경고 메시지가 링크에 의해 생성됩니다.
Warning[Lo009]: [stack usage analysis] the program contains at least one
indirect call. Example: from "_BSP_IntHandler" in bsp_int.o [1]. A
complete list of such functions is in the map file.링크 맵 파일의 STAK USAGE 장에는 다음과 같은 설명이 있습니다.
The following functions perform unknown indirect calls:
"_BSP_IntHandler" in bsp_int.o [1]: 0xffffabd4참고: RX ABI를 준수하기 위해 컴파일러는 밑줄을 추가하여 기호 및 함수 이름에 대한 어셈블리 레이블을 생성합니다. 따라서 여기서 라벨 "_BSP_IntHandler"는 BSP_IntHandler() 함수를 나타냅니다.
이 문제를 해결하려면 개발자가 #pragma calls 지시문을 사용하여 명령문으로 간접 호출할 수 있는 함수를 나열해야 합니다. 이 지시문은 간접 통화 내역서 바로 앞에 삽입하고 가능한 모든 호출자 기능의 목록을 지정해야 합니다. 예를 들어 다음 코드는 함수 포인터를 통해 UartRxHandler(), UartTxHandler() 및 UartFaultHandler() 함수를 간접 호출할 수 있도록 지정합니다.
void BSP_IntHandler (int int_id) {
void (*isr)(void);
……
if (int_id < BSP_INT_SRC_NBR) {
isr = BSP_IntVectTbl[int_id];
#pragma calls=UartRxHandler,UartTxHandler,UartFaultHandler
isr();
}
……
}호출 그래프 루트 정보를 제공
RTOS를 사용하는 다중 태스크 환경에서 각 태스크의 루트 기능은 호출 그래프 루트이기도 합니다. 때때로 링크에 의해 자동으로 식별되지 않습니다. 다른 기능에서 호출하지 않는 것 같으므로 링크는 대신 경고 메시지를 생성합니다.
Warning[Lo008]: [stack usage analysis] at least one function appears
to be uncalled. Example: "_App_TaskJoy" in app.o [1].
A complete list of uncalled functions is in the map file.링크 맵 파일의 STAK USAGE 장에는 다음과 같은 설명이 있습니다.
Uncalled function
"_App_TaskJoy" in app.o [1]: 0xffff992c
……
Uncalled function
"_App_TaskLCD" in app.o [1]: 0xffff9988
……
Uncalled function
"_App_TaskButton" in app.o [1]: 0xffff99f6
……이 문제를 해결하려면 개발자가 #pragma call_graph_root 지시어을 사용하여 특정 함수를 호출 그래프 루트로 식별해야 합니다. 예를 들어 다음과 같습니다.
#pragma call_graph_root="task" // task category
static void App_TaskJoy (void *p_arg)
{ …… }
#pragma call_graph_root="task" // task category
static void App_TaskLCD (void *p_arg)
{ …… }
#pragma call_graph_root="task" // task category
static void App_TaskButton (void *p_arg)
{ …… } #pragma call_graph_root="interrupt" // interrupt category
void OS_CPU_SysTickHandler (void)
{ …… }#pragma call_graph_root="task" // task category
static void App_TaskJoy (void *p_arg)
{ …… }
#pragma call_graph_root="task" // task category
static void App_TaskLCD (void *p_arg)
{ …… }
#pragma call_graph_root="task" // task category
static void App_TaskButton (void *p_arg)
{ …… }#pragma call_graph_root="interrupt" // interrupt category
void OS_CPU_SysTickHandler (void)
{ …… }실제로 태스크 또는 인터럽트 이외의 문자열을 사용하여 호출 그래프 루트 카테고리의 이름을 지정할 수 있습니다. 컴파일러는 인터럽트 및 태스크 기능에 호출 그래프 루트 범주를 자동으로 할당합니다.
스택 사용량 제어 파일을 사용
#pragma 지시어는 소스 파일에 삽입해야 하며, 경우에 따라서는 허용되지 않습니다. 소스 코드를 변경하지 않고도 별도의 스택 사용량 제어 파일이 컴파일러와 링크에 동일한 스택 사용량 정보를 제공할 수 있습니다.
스택 사용량 제어 파일은 *.suc 가 접미사로 포함된 텍스트 파일입니다. 스택 사용량 제어 파일의 경로는 링크 옵션의 고급 탭에서 설정할 수 있습니다.
스택 사용 제어 파일에는 함수, 제외, 가능한 호출, 호출 그래프 루트, 최대 재귀 깊이, 호출 없음 등 몇 가지 유형의 지시어가 사용할 수 있습니다. possible calls 지시어는 간접 호출의 가능한 호출 함수를 지정하는 #pragma 호출과 유사한 효과를 가집니다. 호출 그래프 루트 지시어는 호출되지 않은 함수 그룹을 호출 그래프 루트로 식별하는 #pragma call_graph_root와 유사한 효과를 가집니다.
이전 예에서 사용된 #pragma 지시문을 대체하여 스택 사용량 제어 파일의 내용을 아래에 제시합니다. 참고: 라벨에는 여전히 밑줄 접두사가 필요합니다.
call graph root [task] : _App_TaskJoy [app.o];
call graph root [task] : _App_TaskLCD [app.o];
call graph root [task] : _App_TaskButton [app.o];call graph root [interrupt] : _OS_CPU_SysTickHandler;possible calls _BSP_IntHandler : _UartRxHandler, _UartTxHandler,
_UartFaultHandler;재귀 함수의 반복을 지정
재귀 함수는 직접 또는 간접적으로 자체 호출됩니다. 각 호출은 스택에 자체 데이터를 저장할 수 있습니다. 여러 번 반복한 후 반환되도록 올바르게 설계되지 않으면 스택 오버플로우가 발생할 위험이 높습니다.
빌드 시 실제 반복 횟수를 알 수 없으므로 링커는 재귀 함수에 대한 스택 사용량 정보를 자동으로 검색할 수 없습니다. 다음과 같은 경고 메시지가 링크에 의해 생성됩니다.
Warning[Lo010]: [stack usage analysis] the program contains at least
one instance of recursion for which stack usage analysis has not been
able to calculate a maximum stack depth. One function involved is
"_GLCD_SendCmd. A complete list of all recursion nests is in the map file.링크 맵 파일의 STAK USAGE 장에는 다음과 같은 설명이 있습니다.
The following functions make up recursion nest 0, which has no
maximum recursion depth specified:"_GLCD_SendCmd": 0xffff8aac이 문제를 해결하려면 개발자가 스택 사용량 제어 파일에서 최대 재귀 깊이 지시문을 사용하여 각 재귀 함수에 대한 최대 재귀 깊이를 지정해야 합니다. 스택 사용량 분석은 최대 반복 횟수에 순환 둥지의 가장 깊은 주기의 스택 사용량을 곱한 결과를 기반으로 합니다. 아래 예는 GLCD_SendCmd() 함수에 대한 최대 재귀 깊이를 3으로 설정합니다.
max recursion depth _GLCD_SendCmd : 3;런타임 스택 사용량 추적
정적 스택 사용 분석은 제조 시 이론적인 최대 스택 요구 사항을 계산합니다. 그러나 실제 스택 소비량은 실행 중에 달라질 수 있습니다. IAR Embedded Workbench for RX는 C-SPY 디버거를 통해 구현된 런타임에 스택 사용량을 추적하는 또 다른 접근 방식을 제공합니다. C-SPY는 응용 프로그램 실행을 시작하기 전에 전체 스택 영역을 0xCD와 같은 매직 데이터 패턴으로 채울 수 있습니다. 프로그램을 잠시 실행한 후(가급적이면 특정 테스트 조건에서) SP가 도달한 최고의 위치인 0xCD와 다른 값을 찾을 때까지 스택 메모리를 위에서 확인할 수 있습니다. 0xCD가 여전히 포함된 스택 메모리의 부분은 덮어쓰지 않았으므로 해당 크기만큼 스택 크기를 줄이는 것이 안전합니다. 물론 테스트가 충분히 오래 지속되지 않거나 가능한 모든 런타임 시나리오를 정확하게 반영하지 못한 경우 약간의 추가 공간을 예약하는 것이 현명할 수 있습니다.
런타임 스택 사용량 추적을 활성화하려면 IDE 옵션 대화상자의 스택 범주에서 그래픽 스택 표시 및 스택 사용량 추적 사용을 선택합니다.
스택 창은 View(보기) 메뉴에서 사용할 수 있습니다. 실행이 중지될 때마다 C-SPY는 이 창에서 스택 사용의 그래픽 표현을 업데이트할 수 있습니다.
그래픽 스택 바의 왼쪽 끝은 스택의 하단, 즉 스택이 비어 있을 때의 SP 위치를 나타냅니다. 오른쪽 끝은 스택용으로 예약된 메모리 공간의 끝을 나타냅니다. 어두운 회색 영역은 사용된 스택 메모리를 나타내고 밝은 회색 영역은 사용되지 않은 스택 메모리를 나타냅니다. 스택 사용량이 IDE 옵션 대화 상자에서 설정할 수 있는 임계값을 초과하면 그래픽 스택 막대가 빨간색으로 바뀝니다.
참고: 이 기능은 스택 오버플로우가 발생할 때 이를 감지할 수 없으며, 스택 오버플로가 남긴 기호만 감지할 수 있습니다. 이는 스택 사용을 추적할 수 있는 신뢰할 수 있는 방법이기는 하지만 스택 오버플로우가 감지될 수 있다는 보장은 없습니다. 예를 들어 스택이 경계 근처에서 실제로 바이트를 수정하지 않고 경계 밖에서 잘못 확장될 수 있으며 스택 영역 외부에서 메모리를 수정할 수도 있습니다.