[Arm] 익셉션에 대해 공부해보자!

이 글은 김동현(Austin Kim)님의 '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 책을 참고하여 작성하였음을 밝힙니다!

 

Arm 아키텍처를 처음 공부하면서부터 계속해서 '익셉션'. "익셉션을 발생시킨다"는 말을 많이 보았다. 오늘은 평소 궁금했던 이 부분을 파고려고 한다. 단어의 뜻으로 유추해보자면 무언가 일반적이지 않은 CPU 상황을 만드는 이벤트가 아닐까 싶다.

---

익셉션? 너는 누구니?

익셉션은 CPU 아키텍처마다 지원하는 기능으로, x86, MIPS, Arm, RISC-V 와 같은 아키텍처의 핵심 기능 중 하나이다. x86, MIPS, RISC-V, Arm 아키텍처 기반의 CPU는 각각 머신에 맞게 빌드된 기계어를 실행한다. 대부분의 경우 CPU 코어에서 기계어를 실행하면 기계어의 목적에 따라 구동하지만, 당연하게도 CPU코어가 기계어를 제대로 실행하지 못하는 경우도 있다..

1. 메모리 주소에서 기계어를 가져오지 못한다.
2. CPU 코어가 기계어를 해석할 수 없다.
3. CPU 코어가 접근할 수 없는 메모리 주소에 액세스 하려고 한다.

개발자가 코드가 정상적으로 동작하지 않는 경우 이를 처리하기 위해 예외 처리를 하듯이, CPU코어가 기계어를 정상적으로 실행하지 못하는 상황에서 이를 처리하는 방식을 익셉션이라고 한다. 이러한 익셉션을 처리하는 세부 방식은 아키텍처마다 다르지만 큰 맥락은 같다. 익셉션이 발생하면 익셉션 종류별로 미리 지정된 주소로 프로그램 카운터가 바뀐다는 것!

Arm 아키텍처에서의 익셉션 동작 방식

Arm 프로세서는 익셉션이 발생하면 익셉션을 처리하는 특정 모드로 진입하고, 다음과 같은 동작을 수행한다고 한다.

• 익셉션을 유발한 다양한 정보를 레지스터에 업데이트한다.
• 익셉션 종류별로 이미 정해 놓은 주소로 분기한다.

이는 Armv7과 Armv8모두 같다!

Arm 아키텍처 관점에서의 익셉션

이번에는 Arm 아키텍처 메뉴얼을 참조해보자.

B1.8 Exception handling
An exception causes the processor to suspend program execution to handle an event, such as an externally generated interrupt or an attempt to execute an undefined instruction. Exceptions can be generated by internal and external sources.

B1.8.1 Exception vectors and the exception base address
When an exception is taken, processor execution is forced to an address that corresponds to the type of exception. This address is called the exception vector for that exception.

 

정리해보면, Arm 아키텍처 관점에서 익셉션은 정의되지 않은 기계어를 처리하려고 하거나, 외부에서 발생한 인터럽트와 같은 이벤트를 처리하기 위해 프로세서의 실행을 중단시키는 이벤트이고, 이러한 익셉션이 발생하면 프로세서는 해당 익셉션 타입의 주소로 실행되도록 강제된다. 이 주소를 해당 익셉션을 위한 익셉션 벡터라고 부른다.

소프트웨어 관점에서 익셉션

Arm 공식 문서가 말하는 익셉션의 정의는 그러하고... 소프트웨어 관점으로 익셉션은 두가지 카테고리로 나눌 수 있다고 한다.

• 치명적인 오류:
  - 메모리 어보트 타입 익셉션(prefetch abort, data abort, undefined instruction)
• 운영체제 커널에서 지원하는 기능: 
  - IRQ(인터럽트 서비스 루틴)
  - 소프트웨어 인터럽트(시스템 콜: SVC명령어)

Arm 아키텍처는 소프트웨어 인터럽트를 이용해 OS 커널의 다양한 기능을 구현할 수 있도록 제공한다. 예를들면 시스템콜이 있다. Armv7은 유저 애플리케이션이 실행되는 유저 모드에서 SVC 명령어를 실행하면 슈퍼바이저 모드로 진입하는 동작을 활용해 시스템 콜을 구현한다.

Armv7의 익셉션 더 파고들기

익셉션이란 예외 상황 발생 시 핸들러로 분기시켜주는 그런 하드웨어 인터페이스라는 이해가 생겼다. Armv7 아키텍처의 익셉션과 익셉션 발생 시 Arm 코어가 어떻게 안전하게 실행 흐름을 분기시키는지, 세부 동작에 대해서 더 파고들어보자!

출처: 책 '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리(김동현 저)'

익셉션이 처리되는 순서는 위의 다이어그램을 따른다.

SW적으로 오류가 발생하거나 인터럽트가 들어오면, 관련 레지스터가 업데이트 되고, 동작 모드가 변경된 뒤, 익셉션 벡터로 PC가 브랜치 되어, 익셉션 핸들러가 실행된다. 하나하나 자세히 알아보자.

1. 익셉션 유발 요인

익셉션을 유발하는 요인에는 메모리 어보트(Data Abort, Prefetch Abort, Undefined Instruction), 외부 인터럽트(IRQ/FIQ), 소프트웨어 인터럽트(SVC 명령어 실행 등) 등이 있다.

2. 레지스터 업데이트

Arm 코어는 익셉션을 유발할 때 다음과 같이 레지스터를 변경한다.

• 익셉션이 발생한 시점의 CPSR 레지스터를 변경되는 모드의 SPSR_<mode> 레지스터에 백업
• 익셉션이 발생한 순간에 실행된 주소를 기준으로, 익셉션이 유발된 시점으로 복귀할 주소를 R14_<mode> 레지스터에 백업

이렇게 익셉션이 발생한 순간의 정보를 레지스터에 저장하는 이유는, 익셉션 타입에 따라 익셉션 발생 직전의 모드로 복귀하기 위함이다.

3. 동작 모드 변경

Arm 코어는 유발하는 익셉션의 종류에 따라 동작 모드를 변경한다. 익셉션 종류별로 처리되는 동작 모드는 다음과 같다.

오프셋	익셉션 종류	동작 모드	CPSR[4:0]
0x00	Reset	Supervisor	0b10011
0x04	Undefined Instruction	Undefined	0b11011
0x08	SVC(소프트웨어 인터럽트)	Supervisor	0b10011
0x0C	Prefetch Abort	Abort	0b10111
0x10	Data Abort	Abort	0b10111
0x14	Not used	Not used	Not used
0x18	IRQ interrupt	IRQ	0b10010
0x1C	FIQ interrupt	FIQ	0b10001

Arm 코어는 CPSR 레지스터의 [4:0]비트(CPSR.M 이라고 부르더라)를 업데이트해 익셉션 종류별로 정의된 동작 모드로 변경한다. 이 같은 Arm 아키텍처의 특징을 활용해 OS는 익셉션의 종류별로 실행 흐름을 구분하여 처리할 수 있다고 한다!

(HW 아키텍처가 먼저 저런 기능을 제공하고, SW인 OS가 이를 활용해 여러 기능을 구현한다는 점을 이해했다)

 

4. 익셉션 벡터 테이블에 명시된 익셉션 벡터로 PC 점프

익셉션에 맞게 동작 모드가 변경된 Arm 코어는, 익셉션 종류별로 지정된 익셉션 벡터 엔트리 주소로 PC를 분기한다.

 

5. 익셉션 핸들러 실행

이제 PC가 분기된 익셉션 벡터 주소에 위치한 명령어가 실행된다. 이때 익셉션 벡터에 위치한 명령어나 루틴을 익셉션 핸들러라고 하며 익셉션의 종류에 따라 각자의 핸들러를 가진다.

 

익셉션 타입별로 익셉션 핸들러는 다음과 같이 동작한다.

• 메모리 어보트 타입 익셉션: 시스템 리셋 또는 프로세스 종료
  메모리 어보트 타입 익셉션은 소프트웨어적으로 치명적인 오류가 있을 때 발생하는 익셉션으로, 프로세스를 아예 종료해버리거나 시스템을 리셋하는 방식으로 루틴이 구현되어있다. 이때 익셉션 핸들러에서는 디버깅을 위해 레지스터나 콜 스택과 같은 디버깅 정보를 출력한 다음 프로세스를 종료하거나 시스템을 리셋한다.

• IRQ 익셉션: 인터럽트를 처리하는 인터럽트 서비스 루틴을 실행
  IRQ 익셉션이 유발되면 익셉션 핸들러에서 ISR을 실행한다. IRQ 익셉션은 외부 하드웨어의 변화를 알리기 위한 인터페이스로 동작하기 때문이다. 일반적으로 OS의 커널은 ISR을 통해 인터럽트 핸들러를 호출하며, 인터럽트 핸들러에서는 인터럽트에 대한 적절한 처리를 수행한다.
• 소프트웨어 인터럽트 익셉션: 시스템 콜 핸들러를 실행
  SVC 같은 명령어를 실행해도 익셉션이 유발되며, 이를 소프트웨어 인터럽트 익셉션이라고 한다. SVC 명령어를 실행하면 호출되는 익셉션 핸들러에서 시스템 콜 핸들러로 분기하는 동작을 수행한다.

익셉션의 전체 실행 흐름 정리!

1. 메모리 어보트 타입 익셉션 실행 흐름

메모리 어보트 타입 익셉션이 발생한 직후 ~ 핸들러 종료까지 실행의 흐름은 다음과 같다.

1. [SW 영역] 프로세스가 실행되는 도중에, 메모리 어보트 타입 익셉션을 유발하는 명령어를 실행한다(예를 들면 data abort, prefetch abort, undefined instruction 등).
2. [HW 내부 처리] Arm 프로세서가 익셉션을 감지!
3. [HW 내부 처리] 익셉션을 감지한 Arm 코어가 세가지 동작을 처리.
   1. 익셉션 발생 시점의 동작 모드를 나타내는 CPSR 레지스터를 SPSR_<mode>에 백업한다.
   2. CPSR 레지스터의 [4:0]을 조작해 동작 모드를 변경해준다.
   3. 해당하는 익셉션 벡터의 주소로 PC를 분기한다.
4. [SW 처리] 익셉션 핸들러 실행후 시스템 리셋 혹은 프로세스 종료
   • 유저 애플리케이션일 경우, 유저 프로세스 종료
   • OS 커널에서 유발된 메모리 어보트 익셉션의 경우, 시스템 종료

2. 인터럽트 타입 익셉션 실행 흐름

외부 인터럽트가 들어오는 상황은 구체적으로 어떤 상황일까? 바로 Arm 코어에 연결된 외부 I/O 디바이스(키보드, 마우스, 터치)가 전기 신호를 일으켜 Arm 코어가 하드웨어적으로 이를 받는(감지하는) 상황이다. 이 인터럽트 타입 익셉션의 실행 흐름에 대해 자세히 알아보자.

1. 프로세스가 실행되는 도중, 외부 인터럽트가 들어온다.
2. [HW처리] 이를 감지한 Arm 코어가 IRQ/FIQ 인터럽트 익셉션을 감지한다.
3. [HW처리] Arm 프로세서가 익셉션에 대해 세부 처리를 수행한다.
   1. 익셉션이 발생한 시점의 동작 모드를 SPSR_irq/ SPSR_fiq 레지스터에 저장한다.
   2. CPSR의 M[4:0]필드를 수정하여 동작 모드를 IRQ/ FIQ로 변경하고
   3. 익셉션 벡터 베이스 주소에서 0x18(irq 오프셋)/ 0x1C(fiq 오프셋)을 더한 주소로 PC를 분기한다.
4. PC에 로드된 주소에 있는 인터럽트 서비스 루틴(ISR)이 실행됨!
   
   1. 인터럽트 발생 시점의 레지스터 세트를 프로세스의 stack에 push
   2. ISR을 실행해 인터럽트를 핸들링하는 코드 실행
   3. 인터럽트 핸들러 함수를 호출
5. 인터럽트 익셉션이 발생한 주소로 복귀
   • 스택 공간에 push해둔 레지스터 세트를 Arm 코어 레지스터에 다시 로딩!

여기서 궁금한 점이 생겼다. 메모리 어보트 타입 익셉션 핸들러를 실행할 땐 스택에 레지스터 세트를 push하지 않는데, 왜 인터럽트 서비스 루틴을 실행할땐 스택에 레지스터값을 push해주는 것일까?

그 첫번째 이유는(내가 생각하기엔) ISR내에서 Nested interrupt를 해야할 수 있기 때문이라고 생각한다. ISR1 실행 중, 더 높은 순위의 인터럽트가 발생하면 해당 ISR2를 실행해야하는데, 그렇게 되면 기존 ISR1을 실행하며 보유하고있던 복귀주소 LR값이 ISR2를 실행 후 ISR1로 복귀하기 위한 주소로 덮어씌워지게 된다. 따라서 LR을 포함한 현재 사용하던 범용 레지스터 값들을 스택에 push하여 값을 보존하는 것이 아닐까 추측해본다.

 

3. 소프트웨어 인터럽트 익셉션 실행 흐름

SVC 명령어를 실행하면 Arm 코어는 이를 익셉션의 한 종류로 감지하며, 이를 슈퍼바이저 콜 이라고 한다. SVC명령어는 외부가 아닌 SW 적으로 인터럽트 익셉션이 유발되므로 소프트웨어 인터럽트라고도 하며, 시스템 콜이 발생했다고 표현한다.

이제 실행 흐름을 살펴보자!

1. SVC 명령어 실행
   1. 유저 프로세스가 SVC 명령어를 실행한다.
2. Arm 프로세서가 익셉션을 감지
   1. Arm 코어가 SVC 명령어를 디코딩할 때 슈퍼바이저 콜 익셉션을 유발한다.
3. 익셉션에 대한 Arm 프로세서의 세부 처리
   Arm 코어는 SVC명령어를 만나면 '슈퍼바이저 콜을 통해 소프트웨어 익셉션을 유발하자'라고 판단해 아래의 순서로 레지스터를 설정한다. 참고로 아래 3단계 동작은 HW적으로 Arm 프로세서가 처리한다.
   
   1. SPSR_svc 레지스터에 CPSR을 저장한다.
   2. 동작 모드를 슈퍼바이저 모드로 변경
   3. 익셉션 벡터 베이스 주소에서 0x08을 더한 주소로 PC를 분기
4. 익셉션 핸들러 실행
   
   1. 시스템 콜 테이블에 접근
   2. 시스템 콜 핸들러를 호출
   3. 시스템 콜 핸들러의 서브루틴 실행

OS 관점에서 유저 애플리케이션이 커널에 어떤 서비스를 요청할 때 시스템 콜이 실행된다. 시스템 콜 핸들러에게서는 요청한 서비스를 처리하는 루틴이 실행된다.

SVC나 SMC 같은 명령어를 실행하면 익셉션이 유발되는데, 이를 '트랩됐다'라고 표현한다. Armv7 아키텍처 기준 유저 모드에서 SVC 명령어가 실행되면 유저 모드에서 슈퍼바이저 모드로 트랩된다라고 할 수 있다.