저는 일단 자료구조를 따로 문서로 정리해놓고 분석을 시작합니다. 도구는 vi + ctags + cscope + gdb 정도 사용하구요.. 처음엔 ctags를 사용하니까 필요할때마다 해당 자료형을 볼 수 있어서 따로 정리를 안하고 했었는데, 머리가 나빠서인지 자꾸 자료구조를 잊어버립니다. 그래서 따로 문서로 만들고 그걸 보면서 하니까 그나마 좀 괜찮네요.
저도 소스분석에 관심이 있어서 괜찮은 방법이 없는지 검색도 많이 해봤습니다. 그런데 딱 이거다 할만한 방법을 아직 못찾았네요. 과연 그런게 있을까 싶기도 하구요. 검색중에 아래 문서를 찾았는데 맞는말 같더군요.
우선 그 프로그램이 어떠한 목적으로 만들어진것인지 주변환경을 먼저 파악하는것이 먼저고요.
그럴려면 개발에 관계된 문서 (당근 영문문서지요?) 를 먼저 탐독하고, 그 내용을 보고서, 그 부분중에서 어떠한 부분을 나의 목적에 맞게 수정하겠다는 목표를 가지고 여기저기 디버깅 코드를 삽입해서 동작원리를 이해하면서 접근하는것이 순서 입니다.
무작위로 파고 들어가봐야, 길을 헤메이고 십상이고, 그러면 때러 엎고 다시 시작을 반복하는 무한 루프에 빠지게 됩니다.
먼저 무엇을 어떻게 할것인지 목표부터 세우세요.
그리고 거기에 맞는 툴을 선택하는것이 먼저 입니다.
프로그래밍 기법을 보고 싶다? 꿈도 꾸지 마세요. 차라리 프로그래밍 기법에 대하여 기술한 책을 보는게 낫습니다.
절대 무시하는 것이 아니라, 그런 경험에 빠져서 허우적 거렸던 경험자의 충고 일 뿐입니다.
소스분석을 *어떻게* 하느냐는, 소스분석을 *왜* 해야 하느냐에 따라도 달라질 수 있습니다.
알수 없는 오류를 찾아야 할 경우, 디버깅된 메시지가 있는 경우,
패치만 하고자 하는 경우, 소스를 완전히 분석하고 싶은 경우,
기타 여러가지 소스 분석을 하는 *이유*에 따라서 어떻게 소스 분석을 하느냐가 효율적일지 달라질 수 있습니다.
그것에 따라서 grep만으로도 충분할 경우가 있고, 소스코드를 정독해야 하는 경우도 있죠.
때에 따라서는 소스를 거의 파악조차 하지 못했는데도 논리적으로 틀린 부분을 찾아 패치를 만들 수도 있습니다.
처음에는 무턱대고 소스를 쳐다보고, 이 함수 저 함수 돌아다니는 경우가 많은데 진도가 안나가다 보면 얼마 후에 지치고 포기할 경우도 생깁니다. 이러한 경우라면 먼저 좀 더 작은 목표를 잡아서 다시 시도해 보시길, 여기서 작은 목표라 함은 프로그램의 어떤 기능적 측면이라던지, 알고리즘이 비교적 간단하고 이해하기 쉬운 부분을 찾거나, main함수에 대해서만 보거나, 전체적인 윤곽만 살펴보거나.. (목표하는 바에 따라서 어떤 툴이 목표에 적합한지 찾으실 수 있을 것입니다)
source insight 최고
소스분석에는 source insight 가 최고라고 생각합니다.
기능이야 거의모든 툴이 비슷하다고 보지만, 가장 강력한(빠른) search 기능을 자랑하는 si 가 최고라고 생각합니다.
저는 일단
저는 일단 자료구조를 따로 문서로 정리해놓고 분석을 시작합니다. 도구는 vi + ctags + cscope + gdb 정도 사용하구요.. 처음엔 ctags를 사용하니까 필요할때마다 해당 자료형을 볼 수 있어서 따로 정리를 안하고 했었는데, 머리가 나빠서인지 자꾸 자료구조를 잊어버립니다. 그래서 따로 문서로 만들고 그걸 보면서 하니까 그나마 좀 괜찮네요.
저도 소스분석에 관심이 있어서 괜찮은 방법이 없는지 검색도 많이 해봤습니다. 그런데 딱 이거다 할만한 방법을 아직 못찾았네요. 과연 그런게 있을까 싶기도 하구요. 검색중에 아래 문서를 찾았는데 맞는말 같더군요.
http://codediver.kaist.ac.kr/vBulletin/showthread.php?t=87
그리고 개인적으론 어떤 툴이 좋다는 얘기보다는 어떤 방식으로 분석을 하는지 토론이 이어졌으면 좋겠습니다.
======================
BLOG : http://superkkt.com
======================
BLOG : http://superkkt.com
저도 소스 분석에
저도 소스 분석에 대해서는 superkkt 님께서 링크해놓으신 글 내용과 비슷한 맥락의 생각을 가지고 있습니다. 전에 써두었던 다음과 같은 글도 있구요...
http://kldp.org/node/69521
아무튼 소스 분석은 툴로 하는 게 아니라고 봅니다. 분석 능력은 결코 도구에 의해 늘지 않을 거에요. 개발 경험, 분석 경험 등이 세월을 두고 싸여야 가능할 겁니다.
Orion Project : http://orionids.org
소스 분석이라...
툴은 어디까지나 도우미 일뿐이거덩요.
우선 그 프로그램이 어떠한 목적으로 만들어진것인지 주변환경을 먼저 파악하는것이 먼저고요.
그럴려면 개발에 관계된 문서 (당근 영문문서지요?) 를 먼저 탐독하고, 그 내용을 보고서, 그 부분중에서 어떠한 부분을 나의 목적에 맞게 수정하겠다는 목표를 가지고 여기저기 디버깅 코드를 삽입해서 동작원리를 이해하면서 접근하는것이 순서 입니다.
무작위로 파고 들어가봐야, 길을 헤메이고 십상이고, 그러면 때러 엎고 다시 시작을 반복하는 무한 루프에 빠지게 됩니다.
먼저 무엇을 어떻게 할것인지 목표부터 세우세요.
그리고 거기에 맞는 툴을 선택하는것이 먼저 입니다.
프로그래밍 기법을 보고 싶다? 꿈도 꾸지 마세요. 차라리 프로그래밍 기법에 대하여 기술한 책을 보는게 낫습니다.
절대 무시하는 것이 아니라, 그런 경험에 빠져서 허우적 거렸던 경험자의 충고 일 뿐입니다.
- 겨울아찌 -
- 겨울아찌 -
winchild@gmail.com
그리고 무엇을 하고자 하는지에 따라서도 다릅니다
소스분석을 *어떻게* 하느냐는, 소스분석을 *왜* 해야 하느냐에 따라도 달라질 수 있습니다.
알수 없는 오류를 찾아야 할 경우, 디버깅된 메시지가 있는 경우,
패치만 하고자 하는 경우, 소스를 완전히 분석하고 싶은 경우,
기타 여러가지 소스 분석을 하는 *이유*에 따라서 어떻게 소스 분석을 하느냐가 효율적일지 달라질 수 있습니다.
그것에 따라서 grep만으로도 충분할 경우가 있고, 소스코드를 정독해야 하는 경우도 있죠.
때에 따라서는 소스를 거의 파악조차 하지 못했는데도 논리적으로 틀린 부분을 찾아 패치를 만들 수도 있습니다.
처음에는 무턱대고 소스를 쳐다보고, 이 함수 저 함수 돌아다니는 경우가 많은데 진도가 안나가다 보면 얼마 후에 지치고 포기할 경우도 생깁니다. 이러한 경우라면 먼저 좀 더 작은 목표를 잡아서 다시 시도해 보시길, 여기서 작은 목표라 함은 프로그램의 어떤 기능적 측면이라던지, 알고리즘이 비교적 간단하고 이해하기 쉬운 부분을 찾거나, main함수에 대해서만 보거나, 전체적인 윤곽만 살펴보거나.. (목표하는 바에 따라서 어떤 툴이 목표에 적합한지 찾으실 수 있을 것입니다)
온갖 참된 삶은 만남이다 --Martin Buber