Intel Pin is a very successful tool for dynamic bynary instrumentation and is used widely for program analysis (especially for analysing malicious behaviours when the source code is not available).
One feature of it is FOLLOW_CHILD_PROCESS_CALLBACK, which allows a user to choose whether the instrumentation is enabled or not for each child prosess of the target program. What the documentation says is that the callback is called everytime the target program does exec (in Linux) and the callback may return true/false in accordance to whether the exec’ed child process has to be instrumented.
However in my environment (Debian GNU/Linux 8.5 + gcc 4.8 / 4.9), the callback is not called even when my program does exec and I believe it’s not a fault of my instrumentation code because even a very simple example (for this follow child functionality) provided by Intel itself does not work. This is very bad as in default Pin does not instrument child processes, so I cannot instrument multi-processed programs!
One possible reason might be the compiler, as the README in the tarball says:
you cannot use gcc versions 4.5 or newer to compile Probe mode tools, since these versions create files with a new OS ABI version which is not compatible with the pin kit.
Although I’m not using the Probe mode, the ABI difference might affect anywhere in this kind of binary instrumentation tool.
The problem is that building an older version of gcc is very troublesome, since it relies on a lot of old library versions and even on some old linux kernel headers.

Dirty Hack

So, I decided to do some dirty hack to let Pin instrument my child processes.
Fortunately, the PIN_AddSyscallEntryFunction functionality, which is invoked at every system call, does work. The idea is to use this callback to (TO BE ADDED)