ARM Exception 디버깅 실습

지난 시간에 이어 ARM exception을 강제로 일으켜보고 디버깅해보겠다.  

 

하기 회색 부분을 더블클릭하거나 아이콘을 누른다. 

sort.c 에 breapoint를 설정한다.

112라인에 더블클릭을 하였다.

F8을 눌러 진행시키면 breakpoint 에 멈춘다.

 

Disassembly 창을 보자

현재 프로그램이 수행될 위치, 즉 PC(Program counter)는 초록색 부분이다.

그 다음 수행할 명령어에 우측 마우스 버튼을 누르면

보이는 Show in Memory 버튼을 누른다.

 

해당 값을 0x77777777 로 바꾼다.

다시 Disassembly 탭을 클릭하면, 하기와 같이 ARM 이 인식하지 못하는 명령어(Undefined)라고 표시된다.

F5(step)나 F8(go)를 눌러 수행시키면, 더이상 프로그램이 진행되지 않는다.

F9를 눌러 stop 시키면, 하기와 같이

Undefined handler로 PC값이 위치해있다.

자기 자신으로 branch 하여 일종의 무한 loop의 asm 버전이다.  

이런 상황이 실제 어떻게 하면 벌어질까?

누군가의 코딩 실수로 코드 메모리 영역이 훼손되거나

전압이 불안정하여 코드 메모리 값이 유지되지 못하거나 등

원인은 다양하다.

 

디버깅은 어떻게 해야할까?

 

함수 호출 때 리턴 주소를 남기는 R14, LR(Link Register) 에 우측 마우스 버튼을 눌러

LR이 가리키는 disassembly 주소로 가보자

훼손시켰던 위치가 보인다.

그 외  Stack point(R13, SP)의 메모리 영역에 남아있는 흔적을 이용할 수도 있다.

Stack 동작의 원리를 역이용하는 것이다.

 

또한 MPU 기능을 이용하면, 훼손시키는 순간을 잡을 수 있다. 

Code 영역에 MPU로 write 접근 가능을 막아놓으면

write 시도하는 순간 abort exception이 발생하고

abort 발생이유가 코프로세서 레지스터에 남는다. 

 

물론, 불량의 재현성이 있다면, 처음부터 단계별로 수행하여 찾아낼 수도 있겠지만... 

위와 같이 동작 원리를 이용한다면 더 효율적인 디버깅이 가능할 것이다.