애플리케이션 코드가 아닌 커널 상의 코드(uart, printf…) 에 트랩 코드를 삽입했을 경우, 트랩이 발생하지 않는다.
문제는 거의 대부분의 하드웨어 인터럽트가 수행시간이 비교적 오래 걸리는 출력문과 관련된 루틴에서 발생하기 때문에 99% 이상 트랩을 삽입해도 트랩이 발생하지 않는 커널 상의 코드(uart, printf) 에 잡힌다.
이상한 점은 T32 를 연결해서 트랩코드를 삽입하고 실행하면 제대로 트랩이 발생한다는 점이다. T32 를 연결했을 때와 연결하지 않았을 때의 현상이 달라진 것을 보면, 내 생각에 원인은 타이밍이라고 생각한다.

위에서 언급했지만, 하드웨어 인터럽트의 거의 대부분이 커널 코드에서 발생하기 때문에, replay list 에서 하드웨어 인터럽트를 선택하더라도 트랩이 발생하지 않는다.
다시말해, 하드웨어 인터럽트가 발생했던 시점으로는 갈 수 없으며, 그러므로 디버깅할 수 없다.
현재로서는 커널코드 상에서 하드웨어 인터럽트가 발생하는 것을 의도적으로 record 하지 못하도록 해놓았지만, 이 역시도 근본적인 해결책은 아니다.

1. T32 의 경우를 봤을 때, 타이밍 문제라고 생각해서 타이머 인터럽트의 발생 주기를 늘리거나 줄이는 것
2. 삽입 주소를 변경(혹시라도 특정 코드에서만 트랩이 걸리지는 않는지?)
3. 캐쉬 설정(혹시라도 트랩을 삽입한 코드를 수행하지 않고, 캐쉬를 참조하여 수행하지는 않는지?)
4. 예전 vpos 소스 코드 실행

1. 타이밍을 조절했지만, 결과는 마찬가지 였다.
2. 정확히 애플리케이션 쓰레드의 코드에서는 제대로 트랩이 발생했지만, 그 외의 커널 코드에서는 트랩이 발생하지 않았다.
3. 부트로더와 커널 초기화 시에 수행되는 캐쉬 관련 설정을 지우고 실행했지만, 결과는 같았다.
4. 초기의 vpos 역시, 같은 문제점을 가지고 있었다.

이 문제는 상당히 중요한 문제이다. 하드웨어 인터럽트가 발생했던 시점으로 replay 할 수 없을 뿐 아니라, 체크할 수 조차 없다.
학회 논문은 크게 영향이 없겠지만, 학위 논문의 경우에는 구현 및 실험이 들어가야 한다.
일단은 지금으로서는 문제의 원인에 대해서 파악해야 한다. 해결될 기미가 보이지 않는다면, 새롭게 해야할지도 모른다.

문제는 캐쉬였다. 나는 예전까지 MMU 와 I-Cache, D-Cache 를 모두 disable 시킨 줄 알았다. 하지만, 실제 코드는 그렇지 않았다.
다음은 kernel 초기화 시에 수행되는 어셈 코드이다.

mcr     p15, 0, r0, c7, c7, 0
mcr     p15, 0, r0, c8, c7, 0
 
mrc     p15, 0, r0, c1, c0, 0
bic     r0, r0, #0x00002300
bic     r0, r0, #0x00000087
orr     r0, r0, #0x00000002
orr     r0, r0, #0x00001000   // I-Cache 활성화
mcr     p15, 0, r0, c1, c0, 0
 
mov     r0,#0x0
mrc     p15,0,r0,c1,c0,0
orr     r0,r0,#(1<<12)      // I-Cache 활성화
mcr     p15,0,r0,c1,c0,0

위에서 주석이 달린 부분이 I-Cache 를 활성화 시키는 부분이다. 참고로 I-Cache 를 활성화 시키면, 자주 사용되는 코드(kernel 코드는 while 문으로 무한 루프로 동작하기 때문)는 자동으로 캐쉬에 저장된다. 그래서 한번 캐쉬에 저장되면, 메모리를 직접 엑세스 하여 실행하지 않고 캐쉬에서 바로 실행한다.
이 때문에 thread 로 동작하는 애플리케이션 코드의 경우, kernel 코드와는 달리 캐쉬에 저장되어 있지 않기 때문에 트랩 코드 삽입 시에 바로 트랩이 발생 했었다.

앞의 문제만 해결되면, 간단히 구현될 것 같았던 것이 난관에 부딪혔다.
대부분의 하드웨어 인터럽트는 uart, printf 루틴에서 발생한다고 언급했었다. 문제는 이 루틴이 너무 자주 빈번히 실행된다는 것이다.
로그 리스트에서 하드웨어 인터럽트를 선택해서 해당 PC 주소에 트랩코드를 삽입한다고 하자. 그것이 uart, printf 루틴이면 거의 무한적으로 트랩이 발생할 것이다.
또한 로그 리스트의 카운터로는 같은 루틴의 같은 주소의 PC 값이 수행할 때, 구분할 수 없다.

생각과 실제는 다르다.

1. 직접적인 하드웨어와 관련된 루틴에서의 record 를 막고, 그외의 printf 루틴을 하나더 만든다. 예를 들어 replay_printf() 를 만든다. record 모드에서는 기존의 printf() 루틴으로 수행하여 record 하고, replay 모드에서 출력되는 루틴의 경우, replay_printf() 루틴을 수행하게끔 한다.
2. record 할 프로그램의 printf 관련 루틴을 모두 없앤다.

문제의 해결을 위해서 우선되어야 할 것들은 다음과 같다.

1. 소프트웨어 인터럽트에 대한 record & replay 동작 검증
2. 하드웨어 인터럽트에 대한 record & replay 동작 구현 및 확인