Record & Replay 와 관련하여 4 가지 큰 이슈가 있었다. 다음과 같다.

1. 멀티 코어 환경에서 Global Stop and Record 기능
2. I/O 상황 재현 기능
3. CPU 내부(캐쉬, 파이프라인) 기능
4. Slow replay and debug(기존의 디버거에서의 step by step 기능)

위의 4 가지 이슈 중에서 만만한 것은 하나도 없다.

1. 일단 멀티코어 환경의 H/W 가 있어야 한다는 전제가 있어야 한다. smdk2410 두 대에 uart 로 연결해서 두 대 모두를 stop 시킨다는 것은 각각의 시간차 문제(타이머 레지스터)와 통신을 위한 단계까지는 record 할 수 없다는 생각이다.
2. 여러가지 프로토콜을 가지는 I/O 디바이스가 존재할 수 있다. 단순하게 SD 메모리가 아닌 어떤 명령어를 줘야만 동작하는 디바이스에 대해서는 어떤 식으로 재현할 것인지와 중간 I/O 를 생략하고 record 되었을 당시의 상태로 만들어야 하는 것에 대한 가능 여부
3. 소프트웨어로 접근할 수 있는 방법이 없다. 캐쉬의 경우, 프로그램이 fail 이 발생한 순간과 record 하는 순간에도 계속 바뀐다. 만일 캐쉬의 값을 record 했다고 하더라도, 그 값이 올바로 쓰여졌는지 확인할 방법이 없다. 파이프라인의 경우 역시, 오퍼레이션 할 수 있는 명령어가 없다. 소프트웨어 기반하에서는 제한이 따른다.
4. 생각해 보건데, 4 가지 이슈 중에서 가장 현실성이 높아보인다. 기존의 디버거들이 유사한 방식을 사용하고 있기 때문에 그 쪽 코드를 참고할 필요가 있다.

1. 'I/O 상황 재현 기능' 에 초점을 맞춤
2. Storage, Network 에 디바이스에 대한 I/O 상황 재현
3. 절차적인 과정이 필요한 디바이스(flash) 의 경우, 좀 더 빠른 디버깅을 할 수 있는가?(예를 들면, flash 관련 함수만 수행함으로서 수행 속도를 빠르게 함)
4. 예를 들어 fwrite() 같은 함수를 application 에서 호출하면 체크포인트를 생성하는 시스템 콜이 발생하도록 함

지난번 미팅에서 나온 사항에 대한 구현 가능 여부에 대해 논의했다.

'절차적인 과정이 필요한 디바이스(flash) 의 경우, 좀 더 빠른 디버깅을 할 수 있는가?(예를 들면, flash 관련 함수만 수행함으로서 수행 속도를 빠르게 함)' 의 경우에 대해서는 중간에 연산이 이루어지고, 연산 결과를 디바이스에 write 한다면 실행결과를 일치시킬 수 없기 때문에 불가능하다.

'임베디드 소프트웨어 상에서 디버깅을 잘하자' 라는 주제를 가지고 폭 넓게 생각한다.

지난번 미팅에서 나온 사항에 대한 구체화 방법에 대해서 논의했다.

kgdb 와 kdb 를 vpos 에 포팅하고, 사용법을 쉽게 한다.

1. kgdb 의 개념 확장, 커널 내부의 유용한 정보를 요약 / 알기쉽게 전달 / 성능 측정
2. 이벤트(인터럽트) 를 고려한 디버깅 : 인터럽트가 발생하면, 체크했다가 인터럽트를 재연하는 디버깅

지난번 미팅에서 나온 사항에 대한 논의를 했다.

1. 주기마다 체크포인트를 생성하고, 인터럽트를 저장한다.
2. GDB 스타일의 디버깅 모드를 지원하고, 마지막 체크포인트 상태로 rollback 하며 앞의 부분은 skip 한다.
3. 커널 정보(쓰레드 상태, 메모리 점유율, I/O 상태, 커널 메모리, 버퍼상태)를 표시한다.

1. 단순히 replay 를 해서는 비 결정적인 실행이 될 수 없다. 때문에, 각 프로세스 간에 실행 순서를 기록해야 한다.

1. 다음주 금요일 까지 졸업 논문의 목차 및 섹션을 정해올 것
2. 각 목차와 섹션에 들어갈 내용을 3 ~ 4 줄 정도로 요약할 것(구체화 방법 기술, 관련 연구)

졸업 논문 작성을 위한 가이드 라인 에 대해 논의 했다.

1. '동기(문제점)' 부분이 약하다는 것과 내가 구현해야할 Record & Replay 방법이 기존의 방법과 비교해서 차별화된 점과 강점에 대한 내용이 부족하다.
2. 'Overview' 부분에 Record & Replay 를 하기 까지의 일련의 시나리오를 작성하여 보충한다.
3. 프로그램 작성 → 실행 및 저장(Record) → Replay 및 디버깅

메모리 스냅샷을 저장하는 데, 소요되는 시간을 어떻게 줄일 것인가에 대해서 논의 했다.

1. 타이머 인터럽트가 발생할 때마다, 메모리 스냅샷을 저장하는 방법만으로는 익셉션이 발생했을 때의 상황을 재현하기에 부족하다(예를 들면, 2 개의 쓰레드가 하나의 공유변수를 두고 각각 ++, – 하는 수행을 한다면, 값은 고정되지 않고 변한다).
2. 스케줄러가 호출되는 경로가 비단 타이머 인터럽트 외에도 존재하므로(s/w 인터럽트), 특정 시스템 콜 형태로 호출이 될 때마다 스냅샷을 저장한다.
3. 전체 메모리 스택을 통채로 저장하지 말고, 이벤트 정보를 저장하여 로그를 남긴다(누가, 언제, 메시지 발생시점, 메시지 수신시점등)

위의 문제들만 해결하면, 정확한 재현이 가능한가?

졸업 논문 작성을 위한 가이드 라인 수정 사항 발표 및 record 와 replay 방법에 대해서 논의 했다.

1. 메모리 스냅샷을 저장하는 방법과 이벤트 만을 저장하는 방법 중에 하나를 선택한다. 각각의 장단점을 분석하여 신중히 결정한다.

새로운 이벤트 저장 방식인 Record & Replay 방법에 대해서 논의 했다.

1. 동기화, I/O 관련 이벤트, Thread create, Thread 간 통신, 메세지 큐와 관련한 이벤트 저장 필요
2. PC register 가 동일할 때, register 의 합을 구하는 것이 효율적인가? 같은 pc 값일 때, 구분 할 수 있는 카운터 변수 사용 여부
3. 트랩(trap) 코드를 삽입할 때, XIP(eXecute In Place) 에 대한 가능성 고려

그 동안 구현된 항목과 앞으로 나아가야할 방향에 대해서 논의 했다.

현재 구현된 사항들은 다음과 같다.

하지만, Replay 를 구현하는 방법 자체에서 많은 변화가 있어야 한다는 제안이 나왔다.

1. 현재의 Replay 하는 방법인 트랩 코드를 삽입하여 멈추는 지점까지 수행되어질 때까지 중간의 이벤트를 이용하여 수행해야 함(그래야 실제 Record 될 시의 상황과 똑같이 재현할 수 있음)

예를 들어, Thread1, Thread2 가 있을 때, 실행 순서가 1 → 2 → 1 라고 했을 때, 똑같이 1 → 2 → 1 로 되어야 한다는 것이다.

정보처리학회 제출을 위한 첫번째 논문 미팅을 했다.

수정 사항은 다음과 같다.

1. 제목 : 분석(X) → 추적(O), Analysis → Trace
2. 저자 이름 : Woo-Jong Kim and Min-Soo Ryn, Hanyang
3. <표 1> → Replay Mechanism 섹션으로 이동
4. 요약 수정(첫번째, 두번째 문장)

3월 17일 월요일 수정된 사항을 가지고 논문 미팅 예정

정보처리학회 제출을 위한 두번째 논문 미팅을 했다.

수정 사항은 다음과 같다.

1. 이름 수정 : Min-Soo(X) → Minsoo(O)
2. 내용 수정 : 시점(X) → 상황(O), Time critical(X) 삭제, (그림 1) 에 하드웨어 그림 추가

일단, 위의 수정 사항을 반영하여 학회에 제출하고, 세부사항은 최종 수정본 마감일인 4월 18일까지 수정 보완한다.

앞으로의 방향에 대해서 논의했다.
여름에 우즈베키스탄에서 대한전자공학회 주최로 열리는 학회에 낼 생각이다. 하지만, 마감일이 3월 28일 까지이기 때문에, 낼 수 있을지 확실하지 않다.

다음은 교수님의 생각이다.

1. 현재 vpos 에서 구현된 record & replay 를 현재 사용되는 T32 이나 realview 에서 연동하여 사용 가능하도록 한다.
2. record & replay 를 recoplay 라고 명명한다.
3. 다른 사람들과 연계하여 확장시킨다.

1번에 대한 얘기를 좀 더 하자면, 지금의 record & replay 기능은 디버깅 기능이 약하기 때문에, 기존의 디버거에서 vpos 이미지(vpos + 디버깅 심볼 정보 + record & replay) 를 그대로 사용하여 기존에 제공하는 많은 기능을 사용할 수 있게 한다.
또한 현재 가장 많이 사용하고 있는 T32 나 realview 에서 사용하고 있는 IDE 프로그램과 연동하여, vpos 의 kernel-aware 정보를 볼 수 있게 한다(예를 들어, vpos 의 특정 메모리 번지에 thread 정보를 저장하여, T32 IDE 프로그램에서 그 주소를 dump 하면 그 값을 알 수 있다).

debug_info{
int thread_number; // 현재 쓰레드 수
int current_thread;  // 현재 쓰레드 주소
..
..
..
}

우즈베키스탄에서 대한전자공학회 주최로 열리는 학회에 내 논문을 영어로 번역하여 제출했다. 문제는 내가 정보처리학회에 제출했던 논문의 내용과 상당 부분 달라졌다.

오늘 회의는 나를 제외한 3 명이 함께 했다. 일단 기존의 논문과 비교해서 달라진 것들을 얘기해보겠다.

1. 논문 제목 변경 ('Recoplay: An Effective Record-Replay Approach to Debugging Complex Embedded Software')
2. 3 가지 목적(Goal)
   1. 애플리케이션 태스크 뿐만 아니라 운영체제 또는 하드웨어로 부터 크리티컬한 이벤트 단계를 record & replay 할 수 있다.
   2. 타겟 소프트웨어의 동작이 재생산될 때, 명령어(인스트럭션)레벨의 정확도를 제공할 수 있다.
   3. 어떤 통합의 영향이 없이 기존의 디버거를 사용 할 수 있고 개발자는 single step 이나 breakpoint 설정과 같은 디버깅 기술을 활용할 수 있다.
3. code modifier 는 컴파일된 바이너리 상태의 파일에서 이벤트가 발생한 주소를 추가한다.
4. record & replay 에서 디버깅 명령어를 제공하지 말고 기존의 T32 나 realview 에서 제공하는 것을 사용한다.
5. divx 소스를 record & replay 로 실행하고, 각 함수별, 실행시간을 처음 실행과 replay 실행 시간을 비교한다.

몇몇 부분을 제외하고는 내가 현재 구현한 부분과 크게 다르지 않은 것 같다. 다음은 크게 달라진 부분이다.

1. code modifier 는 컴파일 되어 나온 바이너리 상태의 파일에 이벤트가 발생한 주소를 추가한다고 했는데, 이게 현실적으로 가능한가?
2. record & replay 에서의 디버깅 명령어 모드를 없애고, 기존의 T32 와 같은 디버거에서 지원하는 명령어를 사용한다고 했는데, 그렇다면, 굳이 vpos 에 record & replay 기능을 추가할 필요가 있나? 차라리 그냥 JTAG 장비와 디버깅 툴로 잡아서 보는 편이 훨씬 낫지 않는가?

이러한 점들에 대해서 좀 더 구체적이고 조율이 필요하다.

지난번 회의에 대한 나의 생각에 대한 의견을 얘기했다.

1. code modifier 는 컴파일 되어 나온 바이너리 상태의 파일에 이벤트가 발생한 주소를 추가한다고 했는데, 이게 현실적으로 가능한가?
   → 그냥 기존의 방식대로 처리하면 된다.
2. record & replay 에서의 디버깅 명령어 모드를 없애고, 기존의 T32 와 같은 디버거에서 지원하는 명령어를 사용한다고 했는데, 그렇다면, 굳이 vpos 에 record & replay 기능을 추가할 필요가 있나? 차라리 그냥 JTAG 장비와 디버깅 툴로 잡아서 보는 편이 훨씬 낫지 않는가?
   → 이해가 잘 안되지만 현재의 명령어 모드를 지원하면서, T32 디버거 툴에서 특정 메모리 주소를 덤프했을 때, 정보를 보여주는 방법으로 한다.