소프트웨어 이야기

일단 valgrind는 virtual machine을 사용합니다.   쉽게 말해서 Playstation S/W를 windows에서 돌리기 위해 PS CPU Machine code를 Windows에 돌리는 기술하고 유사한 것이죠.  단지 host와 동일한 CPU machine code를 돌린다는 점이 흥미로울 뿐이죠.

이런 측면에서 보면 CPU machine code에서 malloc이나 free의 JMP routine을 잡아내는 것은 쉬운 일이죠.  이렇게 잡아낸 malloc | realloc | calloc | free와 같은 call을 Memchk 에 보내고, Memchk은 이를 관리합니다.  Memory가 많이 필요합니다.  그런 후 각 memory Read/Write operation에서 Memchk의 상태를 가지고 비교를 하는 것이죠.  많게는 10배 이상 느려지는CPU instruction이 추가로 필요합니다.  여기에는 memset, memclr 등도 당연히 포함되겠죠.  이렇게 하면 un-initialized malloc'd memory, free된 memory사용, malloc over-run등을 확인하는 것은 상당히 쉬운 일입니다.  그렇죠?

valgrind의 버그 리포트를 살펴보면 malloc이 vg_replace_malloc.c:149로 변경되어 있음을 알 수 있습니다.
==2430==    at 0x401A619: malloc (vg_replace_malloc.c:149)

valgrind에서 가장 어려운 부분은 모든 CPU machine code를 완벽하게 emulation하는 것이라 생각합니다.  Option도 워낙 많기 때문에 양적으로 상당한 노력을 요구하는 부분이죠.  그렇다고 해서 부분적으로 emulation은 의미가 없으니까요.

Thread인식을 하기위해서 OS Call 또한 catch를 해야 합니다만, 이 부분은 위와 비슷한 흐름이라 생각됩니다.

valgrind가 실망스러운 부분은 이런 부분입니다.
valgrind는 아래의 버그를 잡지 못합니다.  (FAQ 5.2)

int static[5];

int main(void)
{
  int stack[5];

  static[5] = 0;
  stack [5] = 0;
         
  return 0;
}

static 변수나 array의 check는 하지 못한다는 점이죠.  사실 이런 버그는 잠깐 생각해봐도 상당히 어려운 기술이라는 것을 알 수 있습니다.  Machine code만 보고 int stack[5]가 선언되어 있다는 것을 알아야 하니까요.  struct나 union을 고려에 넣는다면 byte alignment 부터 시작해서 고려해줘야 되는 일이 점차 많아집니다.  게다가 중요한건 compiler의 dependency를 가진다는 점이죠.  Local변수를 어떻게 배치한다는 표준은 없을 테니까요.

다음 valgrind 버전에는 이런 기능이 들어 있었으면 하고 바래봅니다.

제 이야기를 들어보니까 그렇게 어려운 기술 같지는 않죠?
그리고 두 번째의 static 변수 checking은 한번 해볼만한 기술 같죠...

한번 함께 만들어 볼래요?
MIPS용으로 말이죠.