Implement a signal handling component for controlling XRay instrumentation

[llvmbot]

Bugzilla Link	37389
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

Currently, the only ways to enable/disable XRay tracing is through the following mechanisms:

• Environment variable-based configuration. This works great for short-lived processes.

• Programmatic control through the runtime APIs. This works great for long-lived services that already have a control surface that the XRay handling can be plugged in through.

For all other cases where the application is one of the following:

• Interactive: i.e. has a long-running component and dedicated input handling.

• A daemon: i.e. an application that sits in the background, doing periodic work, and has a very limited or constrained control surface, like logging daemons or other system daemons typical in some POSIX environments.

• Self-contained: i.e. an application that has no external control outside of initial start-up, usually acting as a client or a controller of sorts, which only typically performs output operations and has no existing control surface for interactive use-cases.

On POSIX platforms, we have some options:

1. We can use the signal-handling facilities to control the XRay tracing implementation, using one of the signals that are well-defined to be ignored by default (SIGCONT or SIGURG), and dedicate one thread to block on these signals.

2. Use ptrace only to signal the dedicated XRay control thread in the target process to kick-off the tracing implementation.

3. A hybrid of 2 and 1.

This bug is intended to track the work on the in-process control as well as the tool used to coordinate/configure the tracing. That tool is intended to be implemented as a sub-command to the llvm-xray tool in the LLVM distribution.