想問一下各位前輩，
(1)有沒有人整理過valgrind比較新的內部實做文件？
不管什麼部份都好......現在手上雖然有散落一些片段的note，但還是很缺乏(嘆氣)
(2)在大型專案不同版本移植時，遇到API的改動有沒有什麼技巧或章法？另外想問此時方便好用的tool。
目前是用cscope去撈舊名稱，但是會遇到：
(a)macro有時它會認不出來
(b)數個function被merge成一個，但是名稱可能長得不一樣。
(其實這是缺文件的問題，嘆)
(3)不知道有沒有人對Record Replay　debuging有研究的？
即紀錄一隻process做過哪些system call、對fd的操作、non-deterministic的instrucion、排程紀錄......etc
而debug時可以直接按照log倒進去replay，因為去除掉上述的東西後，程式應該要是deterministic的blackbox。
目前想到的non-deterministic的x86/x64 instrucion大概是像rdtscp、rdtsc這種取時間的instruction。
除此之外，不知道有沒有人做過這領域的研究，撞到過有比較不直觀、但其實應該要被紀錄的東西？
/**********************************/
Background:
我跟我的partner最近在做record replay debug的實做，based on Valgrind。
會想要從Valgrind改的原因是：valgrind的instrument tool是對其自帶的VEX IR進行想做的分析。
直接在x86 assembly做操作不是不行，但是最剛開始時，
想要直接在IR層做事就好、不想碰太下面platform dependent的事情。
但是在研究Valgrind內部時遇到 非 常 大的挫折：
(1)Valgrind的實做文件幾乎可以說是out-of-sync。
很多的API改動都沒有註明，而且他還deepy bind on glibc，之前工作環境的glib太新還不能編Orz
(2)他用了不少Macro Magic，例如有時會把一個條件判斷是寫成一個macro，
所以會看到類似這樣的東西:
if VG_CLO_STREQN(arg1,arg2) {/*whatever*/}
else exit();
而這個VG_CLO_STREQN可能在天邊一個奇怪的header裡面，也沒文件說他的功能，追code很耗時間
而且它syntax在不同版本還會不一致，像這個VG_CLO_STREQN在3.9.0是個已經把小括弧包進去的判斷式；
但在3.3.1卻是一段code，前後要補小括號給他。
(3)valgrind本體其實是把各種intrument tool直接static link到coregrind (Valgrind的核心)上，
甚至memcheck這隻最常用的tool會直接改coregrind的程式碼 (用ifdef的macro在編譯期間改動)
所以其實弄了老半天，還是有很的機會要去看x86 assembly
(4)不知道為什麼用gdb debug他會直接SIGSEGV、用callgrind想去生他的dynamic call-graph也噴掉......
我們目前是在把一個Oracle的前輩放出來的proof of concept，
從Valgrind 3.3.1移植到3.9.0。
至今花了近兩個月才build出一堆不能動的alpha（這點其實也是我功力還太差）
事到如今洗頭已經洗一半了，也不能再換框架，但是希望接下來做得比較順一點（嘆氣）
project github:
https://github.com/u1240976/valgrindrr
(目前只能在i386 linux上面build，出來的東西連原本valgrind都會failed...)
POC that should work on valgrind 3.3.1 :
http://goo.gl/BpWUbr