Upstreaming LLVM XRay shared object support

[yosefk]

Not sure this is an "issue" - just don't know of another way to communicate on github... - but, was LLVM XRay shared object support upstreamed to the LLVM project/is there an intent to upstream it?

[jplehr]

Hey, great that you reach out. The support has been upstreamed and should be available as part of current LLVM development.

[yosefk]

Thanks for your reply! Is it a part of the LLVM 20 release or is it currently only available at the development branch?

[yosefk]

FWIW, compiling the latest LLVM and trying a simple test with a shared object isn't working "in the traditional way" - the functions are invisible in the output JSON produced by llvm-xray convert --symbolize --instr_map=./exe --output-format=trace_event ..., and in gdb it looks like the functions in the shared object aren't patched whereas the functions in the main program are patched:

Dump of assembler code for function _Z8shared_fi:
0x00007ffff7fc9110 <+0>: jmp 0x7ffff7fc911b <_Z8shared_fi+11>
0x00007ffff7fc9112 <+2>: nopw 0x200(%rax,%rax,1)

Dump of assembler code for function main:
0x000055555557cad0 <+0>: mov $0x5,%r10d
0x000055555557cad6 <+6>: callq 0x555555577940 <__xray_FunctionEntry>

Should one "opt in" for shared library instrumentation, at LLVM build time / client program runtime / trace decoding time / a subset of the above? Or, did I just clone the wrong version (I did git clone https://github.com/llvm/llvm-project and built the main branch checked out by git by default - was this naive? I'm not fluent in LLVM development...)

[yosefk]

I think I found the commit adding shared object support to XRay - please correct me if this is already outdated and there are later commits extending on this one (beyond machine architecture support):

Author: Sebastian Kreutzer SebastianKreutzer@gmx.net
Date: Fri Oct 25 09:15:25 2024 +0100

Reapply " [XRay] Add support for instrumentation of DSOs on x86_64 (#90959)" (#113548)

I understand from the commit message as well as from briefly testing with the new -fxray-shared compiler flag that support for tracing function calls in shared objects is implemented at build time and run time / tracing time, but function IDs from shared objects recorded in the trace aren't decoded to their symbolic names ATM - again, please correct me if I'm wrong:

This patch does not include any functionality to resolve function IDs
from DSOs for the provided logging/tracing modes. These modes still work
and will record calls from DSOs, but symbol resolution for these
functions in not available.

Thus decoded traces look something like this - the numeric IDs correspond to function calls from shared objects:

{ "name" : "g(int)", "ph" : "B", "tid" : "826074", "pid" : "826073", "ts" : "68640368467.9733", "sf" : "13" },
{ "name" : "f(int)", "ph" : "B", "tid" : "826074", "pid" : "826073", "ts" : "68640368468.0644", "sf" : "14" },
{ "name" : "#16777217", "ph" : "E", "tid" : "826073", "pid" : "826073", "ts" : "68640368474.2117", "sf" : "11" },
{ "name" : "#16777218", "ph" : "E", "tid" : "826073", "pid" : "826073", "ts" : "68640368474.3050", "sf" : "9" },
{ "name" : "g(int)", "ph" : "B", "tid" : "826073", "pid" : "826073", "ts" : "68640368474.3926", "sf" : "2" },
{ "name" : "f(int)", "ph" : "B", "tid" : "826073", "pid" : "826073", "ts" : "68640368474.4839", "sf" : "3" },

[sebastiankreutzer]

Hi! Glad to hear that you are interested in this feature.

You are correct, the builtin XRay modes currently do not support function resolution for shared library calls.
Reason for this is that resolving IDs requires runtime knowledge about the identity and the load order of shared libraries, which cannot be represented in the current XRay format.

I'm working on a patch that solves this issues, by extending the format to allow explicitly embedding function information. A prototype implementation (currently restricted to the basic format) is available here: https://github.com/sebastiankreutzer/llvm-project-xray-dso/tree/xray_func_res
I'm planning to submit a patch soon to get this integrated upstream.

[yosefk]

Thanks for your response and your work!