Hi @cecio ! Thank you for your contribution, I will check it as soon as I get some free time.
But regarding:

As you can see I removed the -m option used here. [...] since I didn't found a reason to keep it

This parameter should not be removed, because it do serve an important purpose. It is for tracing DLLs (https://github.com/hasherezade/tiny_tracer/wiki/Tracing-DLLs#tracing-a-dll-within-an-exe). In this case, the traced module is different than the main module - and we define it by the -m argument. Tracing DLLs is an important feature, for example, some malware samples are shipped in a DLL form. So we cannot just discard it.

Very good point, you are absolutely right. Let me re-work the callback then: I'll modify it to handle this the proper way.

Hi @hasherezade !
I refactored the callback and managed the -m option. Now the entire command line is replicated and modified for the child execution.

Thank you @cecio ! I will just rework a bit the way in which the log is saved. I want it to have a .tag extension, because this is the extension that I am using across my various tools. So it should rather be fullspeed.exe.4316.tag and not fullspeed.exe.tag_4316.log. But it is just a detail, so I will change it later. So far I tested it and seems to work well, so I am merging it as is.

Thanks a lot!

BTW @cecio - I think we don't have to add the follow option to the INI file, because anyways the argument -follow_execv controls whether the new process will be followed or not. So if this argument is set, but in the INI file the follow is disabled, the new process still will be followed, but just with a default initialization (which we may not want). And if the -follow_execv is not added, then the function PIN_AddFollowChildProcessFunction just won't be called.

Are you sure that the process will be followed with default initialization if the callback returns FALSE?
Looking here https://software.intel.com/sites/landingpage/pintool/docs/98547/Pin/html/group__PIN__PROCESS.html

I see the following for FOLLOW_CHILD_PROCESS_CALLBACK

Returns
    TRUE If user is interested to inject Pin (and tool) into child/exec-ed process
    FALSE If user is not interested to inject Pin (and tool) into child/exec-ed process

So it seems that if the callback returns FALSE the child is not injected at all. But may be you tested it directly?
That's why I inserted the option, may be there would be a case where I don't want to inject child (may be for performance reasons? Just guessing).
But anyway, even leaving the option on is fine as well.

Hmm, ok I see, you have the point...

What I tried was, removing this function fully:

and I saw that then PIN followed the child processes:

But indeed when I registered the function and made it return FALSE it is yet different situation, and the effect is the same as if -follow_execv was never added. So there is indeed a benefit from adding this option in the INI file.

yeah, actually the callback is not mandatory, so if you don't set it everything it will be executed with default init as you said.
Thanks a lot! :-)

Thank you! Maybe you already saw it, I reverted back to have this option in the INI, and made some small changes. I think it should be fine now, but if you notice something, please let me know!