[llvm-dev] [XRay] RFC: LLVM-side Changes for nop-sleds

[Dean Michael Berris via llvm-dev]

Thanks for the questions Hayden, please see in-line below some responses.

On Mon, Jul 4, 2016 at 5:39 PM Hayden Livingston <halivingston at gmail.com>
wrote:

> 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?

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160704/8488544c/attachment.html>