想问一下各位前辈，
(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