Call "init" function inside the instrumentation tool?

[rrnewton]

In addition to "upcalls" to captured_syscall, don't we need some kind of initialization function? That is, whatever the instrumentation library on top is, might it not need to initialize some global state?

Alternative 1: attribute constructor

It could have its own __attribute__((constructor)) code, but is that sufficient? That would generally allow executing code before main(), but it would not have the guarantee that it is called before the first call to captured_syscall, which I believe that the systrace library could guarantee.

Alternative 2: conditionals, conditionals, conditionals

The instrumentation library could always check on every captured_syscall if initialization has occurred (read a flag), and if not, call it. This kind of "lazy" initialization has disadvantages if we want to establish external connections or start other asynchronous setup processes in the background.

This kind of check-flag-and-init logic could be in systrace itself, and systrace could essentially call init at the earliest of these two execution points, whichever comes first:

• just before the first call to captured_syscall
• constructor initialization

Either way, the init callback would definitely be called before main()...

[wangbj]

The initialization is done when PTRACE_EVENT_EXEC happened, that's the earliest point possible I could think of we can initialization. It happens before libdet.so is being (LD) preloaded.

[wangbj]

https://github.com/iu-parfunc/systrace/blob/8cc1416991a29c729cd0105601cdf9c08f75bef1/src/traced_task.rs#L568

[rrnewton]

Ok, that's for initializing systrace itself, but what about the initialization of the tool (e.g. libdet.so). I realize I was a bit unclear in the title of this issue, changing it.

[rrnewton]

There, let's always use "tool" to refer to the thing on top, such as libdet, echo, or count.

The "count" tool will be very useful for benchmarking overhead btw. It could go head to head against similar tools for Pin. (Even Linux Perf events could capture these counts I believe, and it would probably be the best overhead wise.)