T1.stack - Embedded 시스템의 Stack 사이즈 관리 문서 원본 보기

<p><strong><span style="font-size: medium;">&lt;&nbsp;Stack overflow를 방지하기 위한 최대 Stack 사용량 분석 &gt;</span></strong></p>
<p>&nbsp;</p>
<h2>Stack이란&hellip;</h2>
<p>Stack은 CPU가 프로그램을 실행하는 동안에 데이터를 저장하는 RAM영역중 하나로, 가장 나중에 입력된 데이터가 가장 먼저 출력되는</p>
<p>&ldquo;LIFO(Last In, First Out)&rdquo; 방식으로 동작한다. 일반적으로 함수 내에서 사용하는 데이터는 함수 호출시에 스택에 저장되고, 함수 종료시에</p>
<p>반환된다. 즉, Stack에 저장되는 데이터의 수명은 해당 코드블록이 실행되는 지속시간으로 볼 수 있다. Stack메모리는 다음과 같은 데이터를</p>
<p>저장 할 수 있다.</p>
<p>-&nbsp;지역 변수<br />-&nbsp;리턴 주소 <br />-&nbsp;함수 인자<br />-&nbsp;컴파일러의 임시 변수 <br />-&nbsp;Context 정보</p>
<p><img style="width: 235px; height: 153px; float: left;" src="/data/wiki/2018-11-13/1542098722.png" alt="" width="367" height="252" /></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Stack은 일반적으로 할당된 메모리 영역 중 상위 주소 메모리를 먼저 사용하고 하위 주소로 커지는 방식(Top-Down)을 사용한다.</p>
<p>개발자는 Stack의 크기를 변경 할 수 있는데, Stack 메모리를 충분히 할당해 두지 않으면 프로그램 동작 시 할당된 Stack 영역을</p>
<p>초과하여 사용하게 되는 Overflow 문제가 발생 한다. Stack Overflow는 대개 전역 변수와 정적 변수가 저장되는 영역을 오염 시키며</p>
<p>Runtime 오류를 발생한다. 예를 들어 값이 손상된 전역 변수가 사용되거나 엉뚱한 코드를 실행하는 경우 등을 들 수 있다.</p>
<p>&nbsp;</p>
<h2>Stack의 관리</h2>
<p>그렇다면, 나의 프로젝트에는 어느 정도의 스택이 필요할까??</p>
<p>적절한 크기의 Stack을 지정하고 프로그램이 문제없이 동작하기 위해서는 최대 Stack 사용량을 반영해야 하지만, 이를 어렵게 하는 많은</p>
<p>요소들이 있다. 먼저, SW의 구조는 점점 복잡 해지고 언제든지 인터럽트 기능이 trigger 될 수 있으며, 우선 순위에 따른 선점 관계에 있는</p>
<p>태스크들이 Stack 메모리를 공유하거나 또는 각각 고유의 Stack 영역을 사용 할 수도 있다. 만약 인터럽트나 태스크가 중첩되어 실행이</p>
<p>가능한 구조이거나 함수 포인터, 재귀 호출을 사용하여 코드를 구현했다면 최대 Stack 사용량을 계산하는 것은 더욱 어려울 수 밖에 없다.</p>
<p>그 밖에 Stack 사용량에 영향을 주는 요소는 컴파일러가 있다. 컴파일러는 타겟 코드를 생성하는 단계에서 함수 블록에서 사용할 Stack의</p>
<p>크기를 결정하는데 이는 함수의 바이너리 명령을 보면 확인 할 수 있다. 아래 main 함수의 경우 0x18 만큼의 Stack을 사용하기 위해</p>
<p>A10(Stack Pointer) 레지스터 값을 변경하는 코드가 존재한다.&nbsp;</p>
<p><img style="width: 337px; height: 102px;" src="/data/wiki/2018-11-13/1542098846.png" alt="" width="371" height="100" /></p>
<p><strong>&lt;그림&gt; </strong>함수 진입시 Stack 포인터를 조절하는 명령어</p>
<p>&nbsp;</p>
<p>변경되는 Stack 포인터의 값이(위의 경우 0x18) 해당 함수의 Stack 영역이며, 이는 컴파일 최적화 옵션 설정에 따라 달라질 수 있다.</p>
<p>위와 같이 프로그램이 사용하는 Stack의 크기를 측정, 관리하는 것은 여러 요인에 인해 매우 어렵기 때문에 SW 개발 시작 단계에서부터</p>
<p>지속적으로 최대 Stack 사용량을 분석하고 관리하는 작업이 필요하다.</p>
<p>&nbsp;</p>
<h2>Stack의 크기 설정</h2>
<p>프로그램의 Stack 사용량 분석이 완료되었다면, 이를 반영하여 Stack의 크기를 변경하는 작업은 컴파일러/링커에서 설정할 수 있다.</p>
<p>만약 RTOS가 적용된 개발 환경이라면 OS 설정시에 TASK/ISR 별로 별도의 Stack 영역을 각자 사용하도록 할지, 하나의 Stack을</p>
<p>공용으로 사용할 것 인지를 설정하고 그 크기를 지정할 수 있다.</p>
<p>Firmware 환경에서는 호출에 의한 함수의 중첩관계를 고려하여 최대 Stack 사용량을 정하고, OS 환경에서는 TASK/ISR 간의 선점 관계를</p>
<p>분석한 뒤 최대 Stack 사용량을 정할 수 있다. 즉, 적절한 Stack 메모리의 크기는 프로그램의 Worst Case Stack 사용량을 고려하여</p>
<p>설정해야 한다.</p>
<p><br />&nbsp;<img style="width: 602px; height: 363px;" src="/data/wiki/2018-11-13/1542098900.png" alt="" width="962" height="593" /><br /><strong>&lt;그림&gt;</strong> Stack 사용량 분석을 통한 효율적인 Stack 크기 할당</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<h2>Worst Case Stack 사용량 분석</h2>
<p>최적의 Stack 크기를 설정하기 위한 최대 Stack 사용량을 분석하는 방법에는 동적으로 사용량을 측정하는 방식과 정적으로 분석하는</p>
<p>방식이 있다. 동적 측정 방식은 최종 통합된 SW를 실 타겟 환경에서 동작하여 최대 Stack 사용량을 직접 확인하는 것이다. 이 방식은</p>
<p>주로 디버거를 이용하며 효율적이고 빠르게 결과를 확인 할 수 있다는 장점이 있다. 하지만 이 방식으로 측정된 최대 Stack 사용량은</p>
<p>Worst Case Stack 사용량이 아닐 수 있다. 테스트 환경에서 주입된 테스트 케이스에 의해 Stack 사용량이 결정되기 때문에 테스트 케이스가</p>
<p>Worst Case 수행 경로를 반영하지 못 할 경우 Worst Case에 대한 Stack 사용량 측정이 불가능하기 때문이다.</p>
<p>&nbsp;</p>
<p><strong>* 동적 측정 방식 </strong>- 테스트 시나리오</p>
<p>제어기 리셋&nbsp;-&gt; 대상 Stack 메모리를 특정 패턴으로 초기화 (ex &ndash; 0xA5A5A5A5) -&gt; &nbsp;제어기 동작 -&gt;&nbsp;테스트 케이스 수행 -&gt; 모든 테스트 수행</p>
<p>-&gt; 패턴이 지워지지 않는 부분을 파악하여 최대 Stack 사용량 계산</p>
<p><img src="/data/wiki/2018-11-13/1542098968.jpg" alt="" /></p>
<p><strong>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;그림&gt;</strong> 디버거를 활용하여 동적으로 Stack 사용량 측정</p>
<p>&nbsp;</p>
<p><br />동적 분석 방식의 또 다른 제약으로는 실 타겟을 기반으로 하는 통합 테스트 환경에서 코드 커버리지를 100% 만족하거나 최악의 수행 경로에</p>
<p>대한 테스트를 수행하기 어렵다는 점이 있다. 같은 맥락으로, 재귀함수가 사용되는 경우라면 해당 재귀함수가 Worst Case로 중첩되어 실행되는</p>
<p>테스트 케이스에 대한 주입도 반영하여 테스트 해야 한다. 따라서 동적 방식의 Worst case Stack 사용량 분석은 테스트 환경을 구축 하는데</p>
<p>많은 비용과 시간이 소요 될 수 밖에 없다.&nbsp;정적 분석 방식은 바이너리 코드나 최종 실행 파일(elf) 기반으로 모든 함수 실행 경로를 분석하여</p>
<p>최종 Call tree를 생성하고 사용량을 측정한다.</p>
<p>&nbsp;</p>
<p><strong>* 정적 측정 방식 </strong>&ndash; 분석 시나리오</p>
<p>모든 함수의 스택 사용량 분석&nbsp;-&gt; 모든 함수의 실행 경로(Call Path)를 분석&nbsp;-&gt; 각 Call Path에서호출되는 함수들의 Stack 크기를 더함</p>
<p>&nbsp;-&gt; 특정 함수기준의 Worst Case Stack 사용량 분석</p>
<p>정적&nbsp;측정 방식의 장점은 다음과 같다.</p>
<p>-&nbsp;Worst Case에 대한 Stack 사용량 분석을 통해 적절한 Stack 크기를 설정 가능<br />-&nbsp;Stack 메모리 최적화가 필요한 경우 최적화 대상을 바로 확인 가능 <br />(각각 Call path별로 Stack 사용량을 분석하기 때문)<br />-&nbsp;함수 Call Tree 분석을 통한 SW 구조 파악 가능</p>
<p>&nbsp;</p>
<h3>**&nbsp;측정 방식에 따른 Worst Case Stack 사용량 분석 결과 비교 **</h3>
<p>대상: RTOS가 적용된 환경, TASK_10ms 함수를 대상으로 테스트</p>
<h4>동적 측정 방식&nbsp;예제</h4>
<p>디버거를 사용하여 실제 타겟 코드를 실행 후 Stack 사용량 측정</p>
<p>(Ex, Task_10ms 의 전용 Stack 영역을 파악하고, 타겟 수행 후 실제 사용된 영역을 확인)</p>
<p><img src="/data/wiki/2018-11-13/1542099195.png" alt="" /><br />&nbsp;<br />TASK_10ms 의 스택중, 0x70002A2B~0x70002AB = <strong>0x28 </strong>만큼의 Stack이 사용된 것으로 측정<br />&nbsp;<img style="width: 670px; height: 448px;" src="/data/wiki/2018-11-13/1542099207.png" alt="" width="811" height="592" /></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<h4>정적 분석 방식 예제</h4>
<p>Stack 분석 솔루션을 사용하여 사용량 분석</p>
<p>동일한&nbsp;Task_10ms 에서&nbsp; 0x72 만큼의 Stack이 사용될 것으로 분석되며,</p>
<p>이는 동적으로 측정한 방식보다 약 3배 정도 많은 Stack 사용될 수 있음을 보여줌</p>
<p><br /><img src="/data/wiki/2018-11-13/1542099284.png" alt="" />&nbsp;</p>
<p>&nbsp;</p>
<p>정적 방식으로 모든 함수의 실행 경로를 파악하려면 함수 포인터에 의한 함수 호출과 재귀함수 호출을 분석하지 않고는 정확한 Call Tree를</p>
<p>만들어 낼 수 없으며, Worst Case Stack 사용량에 대한 분석 결과도 정확하지 않을 수 있다. 아래와 같이 Stack 솔루션을 사용하게 되면</p>
<p>Stack 사용량 측정 과정에서 누락된 재귀 함수와 포인터 함수 호출의 정보를 바로 확인 할 수 있다.</p>
<p>&nbsp;</p>
<h2>T1.stack 분석 기능/결과</h2>
<p><img style="width: 947px; height: 318px;" src="/data/wiki/2018-11-13/1542099326.png" alt="" width="1102" height="374" /><br /><strong> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&lt;그림&gt; </strong>정적 분석 방식을 활용한 Call Tree 분석 및 Stack 사용량 확인</p>
<p>&nbsp;</p>
<p><br />아래 그림은 재귀 함수와 함수 포인터가 사용되는 코드를 분석하여 최종 Stack 사용량 결과를 확인하는 과정을 보여준다.<br /><img style="width: 1042px; height: 364px;" src="/data/wiki/2018-11-13/1542099350.png" alt="" width="1795" height="600" /></p>
<p><strong>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;그림&gt;</strong> 재귀 함수의 중첩 실행 횟수 분석&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <strong>&lt;그림&gt; </strong>함수 포인터를 통해 호출 되는 함수 분석</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><img style="width: 870px; height: 626px;" src="/data/wiki/2018-11-13/1542099452.png" alt="" width="1552" height="965" /></p>
<p><strong>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;그림&gt;</strong> 최종 Call Tree 및 Stack 사용량 분석 완료</p>
<p>&nbsp;</p>
<h2>Run-time Stack Overflow 에러 방지</h2>
<p>Runtime 중 Stack overflow가 발생하는 여부를 확인하는 방법은 앞에서 설명한 동적 측정 방식을 활용하면 된다. Stack 메모리의 마지막 주소에</p>
<p>패턴 값이 지워진 경우 모든 stack이 사용된 것으로 overflow 가 발생했음을 알 수 있다. 하지만 runtime중에는 이를 모니터링 하지 못하기 때문에</p>
<p>overflow로 인한 SW 오/동작을 예방 할 수 없다.</p>
<p>Stack overflow를 방지하기 위해서는 아래 그림과 같이 Stack의 끝 주소 다음에 일정 영역의 메모리를 접근 할 수 없도록 보호 영역을 지정해 주는</p>
<p>것이 하나의 방법이 될 수 있다. 또는 프로세서의 MMU나 MPU와 같은 장치를 이용하여 코드가 실행되는 도중 접근이 불가능하도록 할 수 있으며,</p>
<p>이 경우 특정 코드가 해당 영역에 접근하는 경우 trap이나 exception-handler를 동작시켜 예외 처리를 하도록 하면 stack overflow로 인한 SW의</p>
<p>오동작을 방지 할 수 있다.</p>
<p><br />&nbsp;<img style="width: 320px; height: 247px;" src="/data/wiki/2018-11-13/1542099510.png" alt="" width="499" height="373" /></p>
<p>&lt;그림&gt; 메모리 protection을 활용한 Stack overflow 감지 방법</p>