Thanks for the questions Hayden, please see in-line below some responses.
I have a few meta questions here.
Why should LLVM (and from the patch it seems Clang) favor one
instrumentation system – in this case the XRay instrumentation system
vs. many others that may be possible to add to upstream?
I don’t think there’s any intent to exclude any existing or alternative instrumentation systems from LLVM. At least from our proposal, we’re making sure we’re playing well with any existing current implementations already in LLVM/Clang and others that might come along.
It seems GCC has -finstrument-functions that call into cyg_…
functions. Poor naming choice, but I suppose one thing would be to use
those names. Or better yet, provide a way in commandline to say what
functions are for entry, and what are for exit.
I thought Clang already supported this as an option?
How is this different from hot patching that exists in Windows? I
suppose this feature makes it more accessible?
The differences are multi-fold. Some of them that I can list down are:
XRay aims to not change the functionality of the application/function being instrumented. The sole goal of the XRay instrumentation points are to allow for dynamic enabling/disabling of the instrumentation, and only using the instrumentation points that have been inserted by the compiler. With hot-patching in Windows, as far as I can tell the intent is to update the implementation of a function at runtime completely not just for instrumentation. You can say that XRay may be implemented in a similar manner by re-writing the function being instrumented at runtime and hot-patching the original function implementation, but we’ve chosen not to do that for efficiency reasons (trade-off between cost of instrumentation when “off” and when “on”).
XRay has a very specific goal, which is to generate function call traces for performance debugging. Other instrumentation systems will have different goals, and the hot-patching mechanism is just one of those techniques useful for achieving the various goals. We certainly can allow other uses for XRay (i.e. in the prototype implementation, we have hooks to allow changing what function is called when an instrumentation point is encountered at runtime) but the immediate goal is for generating traces that can be analysed offline.
I hope we can change the name of this thing if it were to be added to
something generic that doesn’t tie us to the runtime libraries needed
for XRay specifically.
I agree we should be able to share common infrastructure in LLVM for adding instrumentation points (there’s an interesting RFC recently for CSI) and I’m all for making it easier to implement things like XRay through the common infrastructure. There’s certainly been talk about consolidating the different options for adding instrumentation into a coherent set of flags in Clang, but I haven’t quite seen talk about common instrumentation infrastructure support in LLVM. My hope is, if this is something the community will find useful, that we can gain consensus or at least share a clear direction. I’d be happy to do the work if that means we can get XRay functionality supported as one of the many possible implementations in LLVM.
I’m happy to have a conversation about being able to make alternative instrumentation systems easier to implement with the work to support XRay in LLVM, if that makes it at least clear that XRay isn’t being proposed as the “one true way” for instrumenting Clang/LLVM-built binaries. I’m even willing to try and iterate on the interfaces and/or implementations in LLVM to make XRay-like things be built on top of LLVM.
As for naming, I think being able to specify from a command-line (of Clang, or some other llvm-* tools) the string ‘xray’ makes it easier to search for, document, and “teach”. The vision is, if it’s possible, to have many of these instrumentation implementations live under a single flag like ‘-finstrument=’. For now though any talk of that might be premature if we’re only going to have ‘-finstrument=profile’ and ‘-finstrument=xray’.
Does that make sense?