[Profiler] Change profiler to use the libdatadog dynamic library instead #6301

gleocadie · 2024-11-18T16:49:22Z

Summary of changes

Use libdatadog shared library instead of static link against it.

Reason for change

Tracer is going to use the Rust crate datapipeline to send their traces and so. This C API for datapipeline will be part of the libdatadog shared file.
Since we cannot static link the profiler and the tracer against libdatadog (two Rust runtimes in the same process would bring hell), we need to use the dynamic library (Linux sofile and Windows dll).

This PR is a first step: Having profiler using the shared library and ensuring that it works.

Implementation details

Linux: Use RPATH in the ELF to instruct the dynamic loader where to look for libdatadog dynamic library.
Update FindLibDatadog.cmake to copy libdatadog sofile in the output of the cmake library
Windows: Use LoadLibraryEx in the Native loader to instruct the dynamic loader where to look for libdatadog dynamic library.
Update MSI
Update Nuke Build

Test coverage

The current tests must not fail.
I manually checked the symbols and packages.

Other details

datadog-ddstaging · 2024-11-18T17:17:37Z

Datadog Report

Branch report: gleocadie/profiler-use-libdatadog-dyn
Commit report: 279fa6b
Test service: dd-trace-dotnet

✅ 0 Failed, 252938 Passed, 2476 Skipped, 20h 44m 38.62s Total Time

andrewlock · 2024-11-18T17:21:15Z

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing the following branches/commits:

Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times:

Welch test with statistical test for significance of 5%
Only results indicating a difference greater than 5% and 5 ms are considered.

Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard.

Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph).

gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.6.2) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (69ms)  : 67, 71
     .   : milestone, 69,
    master - mean (70ms)  : 66, 73
     .   : milestone, 70,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (1,005ms)  : 985, 1024
     .   : milestone, 1005,
    master - mean (1,005ms)  : 982, 1028
     .   : milestone, 1005,

gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (102ms)  : 101, 104
     .   : milestone, 102,
    master - mean (102ms)  : 101, 104
     .   : milestone, 102,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (688ms)  : 670, 705
     .   : milestone, 688,
    master - mean (687ms)  : 671, 702
     .   : milestone, 687,

gantt
    title Execution time (ms) FakeDbCommand (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (89ms)  : 87, 91
     .   : milestone, 89,
    master - mean (89ms)  : 87, 92
     .   : milestone, 89,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (646ms)  : 629, 662
     .   : milestone, 646,
    master - mean (643ms)  : 628, 658
     .   : milestone, 643,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (190ms)  : 187, 194
     .   : milestone, 190,
    master - mean (190ms)  : 185, 195
     .   : milestone, 190,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (1,108ms)  : 1083, 1134
     .   : milestone, 1108,
    master - mean (1,104ms)  : 1079, 1129
     .   : milestone, 1104,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (269ms)  : 265, 273
     .   : milestone, 269,
    master - mean (269ms)  : 264, 273
     .   : milestone, 269,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (875ms)  : 851, 900
     .   : milestone, 875,
    master - mean (875ms)  : 848, 902
     .   : milestone, 875,

gantt
    title Execution time (ms) HttpMessageHandler (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6301) - mean (261ms)  : 257, 265
     .   : milestone, 261,
    master - mean (261ms)  : 257, 265
     .   : milestone, 261,

    section CallTarget+Inlining+NGEN
    This PR (6301) - mean (861ms)  : 820, 902
     .   : milestone, 861,
    master - mean (858ms)  : 826, 890
     .   : milestone, 858,

andrewlock · 2024-11-18T20:21:50Z

Benchmarks Report for tracer 🐌

Benchmarks for #6301 compared to master:

2 benchmarks are faster, with geometric mean 1.234
1 benchmarks are slower, with geometric mean 1.126
1 benchmarks have more allocations

The following thresholds were used for comparing the benchmark speeds:

Mann–Whitney U test with statistical test for significance of 5%
Only results indicating a difference greater than 10% and 0.3 ns are considered.

Allocation changes below 0.5% are ignored.

Benchmark details

Benchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Gen 2	Allocated
master	`StartStopWithChild`	net6.0	7.91μs	44.2ns	276ns	0.0153	0.00764	0	5.61 KB
master	`StartStopWithChild`	netcoreapp3.1	10.3μs	54.7ns	371ns	0.0201	0.0101	0	5.81 KB
master	`StartStopWithChild`	net472	16.1μs	49.8ns	193ns	1.04	0.321	0.0964	6.21 KB
#6301	`StartStopWithChild`	net6.0	7.83μs	41.4ns	227ns	0.0167	0.00835	0	5.61 KB
#6301	`StartStopWithChild`	netcoreapp3.1	10.3μs	56.7ns	321ns	0.0257	0.0103	0	5.8 KB
#6301	`StartStopWithChild`	net472	16μs	40ns	155ns	1.03	0.29	0.094	6.21 KB

Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`WriteAndFlushEnrichedTraces`	net6.0	500μs	173ns	670ns	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	647μs	539ns	2.09μs	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	net472	852μs	1.01μs	3.9μs	0.419	3.3 KB
#6301	`WriteAndFlushEnrichedTraces`	net6.0	493μs	395ns	1.53μs	0	2.7 KB
#6301	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	652μs	405ns	1.52μs	0	2.7 KB
#6301	`WriteAndFlushEnrichedTraces`	net472	847μs	400ns	1.5μs	0.422	3.3 KB

Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendRequest`	net6.0	131μs	442ns	1.71μs	0.192	14.47 KB
master	`SendRequest`	netcoreapp3.1	147μs	163ns	632ns	0.222	17.27 KB
master	`SendRequest`	net472	0.0158ns	0.00432ns	0.0167ns	0	0 b
#6301	`SendRequest`	net6.0	129μs	242ns	938ns	0.195	14.47 KB
#6301	`SendRequest`	netcoreapp3.1	150μs	92.9ns	360ns	0.225	17.27 KB
#6301	`SendRequest`	net472	0.000367ns	0.000171ns	0.000661ns	0	0 b

Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ More allocations ⚠️

More allocations ⚠️ in #6301

Benchmark	Base Allocated	Diff Allocated	Change	Change %
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces‑netcoreapp3.1	41.52 KB	41.73 KB	214 B	0.52%

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Gen 2	Allocated
master	`WriteAndFlushEnrichedTraces`	net6.0	585μs	3.35μs	25.5μs	0.571	0	0	41.59 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	706μs	3.66μs	18.3μs	0.357	0	0	41.52 KB
master	`WriteAndFlushEnrichedTraces`	net472	892μs	3.99μs	14.4μs	8.8	2.64	0.44	53.35 KB
#6301	`WriteAndFlushEnrichedTraces`	net6.0	607μs	3.57μs	35μs	0.579	0	0	41.73 KB
#6301	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	728μs	4.26μs	41.1μs	0.329	0	0	41.73 KB
#6301	`WriteAndFlushEnrichedTraces`	net472	870μs	4.1μs	15.9μs	8.3	2.62	0.437	53.34 KB

Benchmarks.Trace.DbCommandBenchmark - Slower ⚠️ Same allocations ✔️

Slower ⚠️ in #6301

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.DbCommandBenchmark.ExecuteNonQuery‑net6.0	1.126	1,239.46	1,395.77

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`ExecuteNonQuery`	net6.0	1.24μs	0.952ns	3.56ns	0.0142	0	1.02 KB
master	`ExecuteNonQuery`	netcoreapp3.1	1.79μs	4.6ns	17.2ns	0.014	0	1.02 KB
master	`ExecuteNonQuery`	net472	2.04μs	2.69ns	10.4ns	0.156	0.00102	987 B
#6301	`ExecuteNonQuery`	net6.0	1.4μs	1.86ns	7.19ns	0.014	0	1.02 KB
#6301	`ExecuteNonQuery`	netcoreapp3.1	1.85μs	2.72ns	10.5ns	0.014	0	1.02 KB
#6301	`ExecuteNonQuery`	net472	2.18μs	3.17ns	12.3ns	0.157	0.00109	987 B

Benchmarks.Trace.ElasticsearchBenchmark - Faster 🎉 Same allocations ✔️

Faster 🎉 in #6301

Benchmark	base/diff	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch‑net6.0	1.125	1,352.93	1,202.29

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`CallElasticsearch`	net6.0	1.35μs	0.906ns	3.39ns	0.0135	976 B
master	`CallElasticsearch`	netcoreapp3.1	1.52μs	1.65ns	5.72ns	0.0128	976 B
master	`CallElasticsearch`	net472	2.61μs	2.55ns	9.89ns	0.157	995 B
master	`CallElasticsearchAsync`	net6.0	1.41μs	0.842ns	3.15ns	0.0134	952 B
master	`CallElasticsearchAsync`	netcoreapp3.1	1.68μs	0.757ns	2.93ns	0.0136	1.02 KB
master	`CallElasticsearchAsync`	net472	2.71μs	1.63ns	6.32ns	0.166	1.05 KB
#6301	`CallElasticsearch`	net6.0	1.2μs	0.894ns	3.34ns	0.0138	976 B
#6301	`CallElasticsearch`	netcoreapp3.1	1.65μs	0.579ns	2.17ns	0.0131	976 B
#6301	`CallElasticsearch`	net472	2.59μs	2.58ns	9.98ns	0.158	995 B
#6301	`CallElasticsearchAsync`	net6.0	1.32μs	0.359ns	1.29ns	0.0131	952 B
#6301	`CallElasticsearchAsync`	netcoreapp3.1	1.67μs	0.707ns	2.74ns	0.0142	1.02 KB
#6301	`CallElasticsearchAsync`	net472	2.59μs	1.59ns	6.15ns	0.166	1.05 KB

Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`ExecuteAsync`	net6.0	1.33μs	0.607ns	2.27ns	0.0134	952 B
master	`ExecuteAsync`	netcoreapp3.1	1.62μs	1.56ns	6.04ns	0.0121	952 B
master	`ExecuteAsync`	net472	1.83μs	0.464ns	1.8ns	0.145	915 B
#6301	`ExecuteAsync`	net6.0	1.32μs	0.287ns	1.07ns	0.0132	952 B
#6301	`ExecuteAsync`	netcoreapp3.1	1.73μs	0.637ns	2.38ns	0.0128	952 B
#6301	`ExecuteAsync`	net472	1.81μs	0.567ns	2.12ns	0.145	915 B

Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendAsync`	net6.0	4.46μs	2.63ns	9.85ns	0.0313	2.31 KB
master	`SendAsync`	netcoreapp3.1	5.21μs	1.38ns	4.98ns	0.037	2.85 KB
master	`SendAsync`	net472	7.5μs	1.48ns	5.34ns	0.492	3.12 KB
#6301	`SendAsync`	net6.0	4.46μs	5.12ns	19.8ns	0.0311	2.31 KB
#6301	`SendAsync`	netcoreapp3.1	5.26μs	1.85ns	7.17ns	0.0371	2.85 KB
#6301	`SendAsync`	net472	7.51μs	1.73ns	6.46ns	0.496	3.12 KB

Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	1.45μs	0.72ns	2.7ns	0.0232	1.64 KB
master	`EnrichedLog`	netcoreapp3.1	2.26μs	0.821ns	3.07ns	0.0218	1.64 KB
master	`EnrichedLog`	net472	2.57μs	0.96ns	3.72ns	0.249	1.57 KB
#6301	`EnrichedLog`	net6.0	1.47μs	0.683ns	2.65ns	0.0228	1.64 KB
#6301	`EnrichedLog`	netcoreapp3.1	2.2μs	0.947ns	3.67ns	0.0219	1.64 KB
#6301	`EnrichedLog`	net472	2.47μs	0.82ns	3.07ns	0.249	1.57 KB

Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`EnrichedLog`	net6.0	111μs	102ns	397ns	0.0557	0	4.28 KB
master	`EnrichedLog`	netcoreapp3.1	115μs	98.7ns	369ns	0	0	4.28 KB
master	`EnrichedLog`	net472	150μs	130ns	486ns	0.673	0.224	4.46 KB
#6301	`EnrichedLog`	net6.0	111μs	119ns	459ns	0.0555	0	4.28 KB
#6301	`EnrichedLog`	netcoreapp3.1	115μs	189ns	733ns	0	0	4.28 KB
#6301	`EnrichedLog`	net472	149μs	109ns	408ns	0.665	0.222	4.46 KB

Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	3.22μs	0.689ns	2.48ns	0.0306	2.2 KB
master	`EnrichedLog`	netcoreapp3.1	4.14μs	1.42ns	5.32ns	0.0309	2.2 KB
master	`EnrichedLog`	net472	4.8μs	1.85ns	7.15ns	0.32	2.02 KB
#6301	`EnrichedLog`	net6.0	3.07μs	1.4ns	5.41ns	0.0307	2.2 KB
#6301	`EnrichedLog`	netcoreapp3.1	4.07μs	0.983ns	3.41ns	0.0289	2.2 KB
#6301	`EnrichedLog`	net472	4.79μs	2.35ns	9.09ns	0.319	2.02 KB

Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendReceive`	net6.0	1.4μs	0.409ns	1.58ns	0.016	1.14 KB
master	`SendReceive`	netcoreapp3.1	1.73μs	0.553ns	2.14ns	0.0155	1.14 KB
master	`SendReceive`	net472	2.08μs	0.914ns	3.54ns	0.183	1.16 KB
#6301	`SendReceive`	net6.0	1.47μs	0.718ns	2.59ns	0.016	1.14 KB
#6301	`SendReceive`	netcoreapp3.1	1.76μs	1.06ns	3.96ns	0.015	1.14 KB
#6301	`SendReceive`	net472	2.04μs	0.967ns	3.75ns	0.183	1.16 KB

Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	2.75μs	2.48ns	8.94ns	0.0219	1.6 KB
master	`EnrichedLog`	netcoreapp3.1	3.95μs	2.75ns	10.6ns	0.0216	1.65 KB
master	`EnrichedLog`	net472	4.44μs	1.98ns	7.39ns	0.323	2.04 KB
#6301	`EnrichedLog`	net6.0	2.88μs	1.05ns	4.07ns	0.0216	1.6 KB
#6301	`EnrichedLog`	netcoreapp3.1	3.86μs	8.73ns	33.8ns	0.023	1.65 KB
#6301	`EnrichedLog`	net472	4.32μs	3.86ns	14.9ns	0.323	2.04 KB

Benchmarks.Trace.SpanBenchmark - Faster 🎉 Same allocations ✔️

Faster 🎉 in #6301

Benchmark	base/diff	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.SpanBenchmark.StartFinishSpan‑net472	1.354	779.32	575.44

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`StartFinishSpan`	net6.0	403ns	0.165ns	0.638ns	0.00804	576 B
master	`StartFinishSpan`	netcoreapp3.1	582ns	0.466ns	1.81ns	0.00773	576 B
master	`StartFinishSpan`	net472	779ns	0.225ns	0.87ns	0.0915	578 B
master	`StartFinishScope`	net6.0	506ns	0.144ns	0.559ns	0.00988	696 B
master	`StartFinishScope`	netcoreapp3.1	712ns	0.464ns	1.8ns	0.00954	696 B
master	`StartFinishScope`	net472	802ns	0.386ns	1.5ns	0.104	658 B
#6301	`StartFinishSpan`	net6.0	401ns	0.166ns	0.575ns	0.00808	576 B
#6301	`StartFinishSpan`	netcoreapp3.1	567ns	0.501ns	1.87ns	0.0077	576 B
#6301	`StartFinishSpan`	net472	576ns	0.218ns	0.786ns	0.0917	578 B
#6301	`StartFinishScope`	net6.0	490ns	0.154ns	0.598ns	0.00978	696 B
#6301	`StartFinishScope`	netcoreapp3.1	734ns	0.415ns	1.61ns	0.00934	696 B
#6301	`StartFinishScope`	net472	840ns	0.336ns	1.3ns	0.104	658 B

Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`RunOnMethodBegin`	net6.0	656ns	0.153ns	0.572ns	0.00985	696 B
master	`RunOnMethodBegin`	netcoreapp3.1	876ns	0.393ns	1.52ns	0.00925	696 B
master	`RunOnMethodBegin`	net472	1.1μs	0.324ns	1.25ns	0.104	658 B
#6301	`RunOnMethodBegin`	net6.0	596ns	0.324ns	1.26ns	0.00988	696 B
#6301	`RunOnMethodBegin`	netcoreapp3.1	947ns	0.451ns	1.75ns	0.0095	696 B
#6301	`RunOnMethodBegin`	net472	1.13μs	0.381ns	1.47ns	0.104	658 B

chrisnas

LGTM

andrewlock

Thanks!

andrewlock · 2025-02-04T12:11:32Z

profiler/Directory.Build.targets

+    <TopLevelDeployDirectoryBase Condition="'$(DeployToMonitoringHome)' == 'True'">$(EnlistmentRoot)\shared\bin\monitoring-home</TopLevelDeployDirectoryBase>
+    <TopLevelDeployDirectoryBase Condition="'$(DeployToMonitoringHome)' != 'True'">$(BuildOutputRoot)\DDProf-Deploy</TopLevelDeployDirectoryBase>


I know this is just things moving around, but I'd Really like to ditch a bunch of this soon if possible, and deploy everything to the "standard" directories instead (which are controlled in CI by env vars etc too). Just an aside, not suggesting we do anything about it now! 😄

🙏 I'm always stressed out when I have to modify those files...

andrewlock · 2025-02-04T12:15:44Z

shared/src/msi-installer/shared/Files.wxs

+    <ComponentGroup Id="Shared.Files.Libdatadog.64" Directory="INSTALLFOLDER.win_x64">
+      <Component Win64="yes">
+        <File Id="libdatadog"
+              Source="$(var.MonitoringHomeDirectory)\win-x64\datadog_profiling_ffi.dll"


Is this only ever going to be the profiling ffi dll? If so, would it make more sense for this to be in the profiler definition .wxs file, rather than in shared? And if it's going to be more than the profiling_ffi, does it make sense for the file to be called something different? e.g. libdatadog.ffi.dll or something?

There is plan from libdatadog repo to rename this libdatadog_profiling.dll.

Any progress on that renaming? And to clarify, is this only an ffi for the profiling functionality? Will we have additional dlls for other ffi (for data pipelin etc)

not yet.
it's a ffi for profiler/data-pipeline/crash-tracking/... (whatever we decide to have in it)

Will we have additional dlls for other ffi (for data pipelin etc)

Nop, the goal is to have only one

andrewlock · 2025-02-04T12:17:58Z

tracer/build/_build/Build.Profiler.Steps.cs

            //
            // See also the ValidateNativeTracerGlibcCompatibility Nuke task and the checks
            // in shared/src/Datadog.Trace.ClrProfiler.Native/cor_profiler.cpp#L1279
            var expectedGlibcVersion = IsArm64
-                ? new Version(2, 28)
+                ? new Version(2, 18)


Hmmm... this is actually a little concerning to me 🤔 I assume this has gone done not because you've removed requirements from the profiler, but rather those requirements have shifted into the libdatadog files... To avoid issues, and to keep this check meaningful, we presumably need to check the libdatadog/ffi compatibility, as well no? 🤔

andrewlock · 2025-02-04T12:30:50Z

tracer/build/_build/Build.Shared.Steps.cs

+    Target PublishLibdatadog => _ => _
+        .Unlisted()
+        .DependsOn(PublishLibdatadogWindows)
+        .DependsOn(PublishLibdatadogLinux);
+
+    Target PublishLibdatadogWindows => _ => _
+        .Unlisted()
+        .OnlyWhenStatic(() => IsWin)
+        .After(CompileProfilerNativeSrc)
+        .Executes(() =>
+        {
+            const string fileName = "datadog_profiling_ffi";
+            foreach (var architecture in ArchitecturesForPlatformForProfiler)
+            {
+                var sourceDir = ProfilerDeployDirectory / $"win-{architecture}";
+                var source = sourceDir / $"{fileName}.dll";
+                var dest = MonitoringHomeDirectory / $"win-{architecture}";
+                CopyFileToDirectory(source, dest, FileExistsPolicy.Overwrite);
+
+                source = sourceDir / $"{fileName}.pdb";
+                dest = SymbolsDirectory / $"win-{architecture}" / Path.GetFileName(source);
+                CopyFile(source, dest, FileExistsPolicy.Overwrite);
+            }
+        });
+
+    Target PublishLibdatadogLinux => _ => _
+        .Unlisted()
+        .OnlyWhenStatic(() => IsLinux)
+        .After(CompileProfilerNativeSrc)
+        .Executes(() =>
+        {
+            var (arch, _) = GetUnixArchitectureAndExtension();
+            var sourceDir = ProfilerDeployDirectory / arch;
+            EnsureExistingDirectory(MonitoringHomeDirectory / arch);
+
+            var files = new[] { "libdatadog_profiling.so" };
+            foreach (var file in files)
+            {
+                var source = sourceDir / file;
+                var dest = MonitoringHomeDirectory / arch / file;
+                CopyFile(source, dest, FileExistsPolicy.Overwrite);
+            }
+        });


I'm generally trying to reduce the number of targets we have (one day hoping to have it down to a number we can actually understand 😅). I realise you just used existing patterns with this, but I'm trying to change those patterns now 😄

Worst case, we could combine these three into a single target:

Suggested change

Target PublishLibdatadog => _ => _

.Unlisted()

.DependsOn(PublishLibdatadogWindows)

.DependsOn(PublishLibdatadogLinux);

Target PublishLibdatadogWindows => _ => _

.Unlisted()

.OnlyWhenStatic(() => IsWin)

.After(CompileProfilerNativeSrc)

.Executes(() =>

{

const string fileName = "datadog_profiling_ffi";

foreach (var architecture in ArchitecturesForPlatformForProfiler)

{

var sourceDir = ProfilerDeployDirectory / $"win-{architecture}";

var source = sourceDir / $"{fileName}.dll";

var dest = MonitoringHomeDirectory / $"win-{architecture}";

CopyFileToDirectory(source, dest, FileExistsPolicy.Overwrite);

source = sourceDir / $"{fileName}.pdb";

dest = SymbolsDirectory / $"win-{architecture}" / Path.GetFileName(source);

CopyFile(source, dest, FileExistsPolicy.Overwrite);

}

});

Target PublishLibdatadogLinux => _ => _

.Unlisted()

.OnlyWhenStatic(() => IsLinux)

.After(CompileProfilerNativeSrc)

.Executes(() =>

{

var (arch, _) = GetUnixArchitectureAndExtension();

var sourceDir = ProfilerDeployDirectory / arch;

EnsureExistingDirectory(MonitoringHomeDirectory / arch);

var files = new[] { "libdatadog_profiling.so" };

foreach (var file in files)

{

var source = sourceDir / file;

var dest = MonitoringHomeDirectory / arch / file;

CopyFile(source, dest, FileExistsPolicy.Overwrite);

}

});

Target PublishLibdatadog => _ => _

.Unlisted()

.After(CompileProfilerNativeSrc)

.Executes(() =>

{

if (IsWin)

{

const string fileName = "datadog_profiling_ffi";

foreach (var architecture in ArchitecturesForPlatformForProfiler)

{

var sourceDir = ProfilerDeployDirectory / $"win-{architecture}";

var source = sourceDir / $"{fileName}.dll";

var dest = MonitoringHomeDirectory / $"win-{architecture}";

CopyFileToDirectory(source, dest, FileExistsPolicy.Overwrite);

source = sourceDir / $"{fileName}.pdb";

dest = SymbolsDirectory / $"win-{architecture}" / Path.GetFileName(source);

CopyFile(source, dest, FileExistsPolicy.Overwrite);

}

}

else (IsLinux)

{

var (arch, _) = GetUnixArchitectureAndExtension();

var sourceDir = ProfilerDeployDirectory / arch;

EnsureExistingDirectory(MonitoringHomeDirectory / arch);

var files = new[] { "libdatadog_profiling.so" };

foreach (var file in files)

{

var source = sourceDir / file;

var dest = MonitoringHomeDirectory / arch / file;

CopyFile(source, dest, FileExistsPolicy.Overwrite);

}

}

});

but I think best case, we could do this copying as part of the existing PublishProfiler step? Especially as this is a required step for the profiler to work... Ideally it would reduce some of the duplication in terms of finding paths and directories etc which this presumably introduces?

Good point. I did that in the forthcoming event that the tracer will have to use this lib. I got a bit to far ahead :P
I'm make it part of PublishProfiler .
We'll revisit it when integrating it for the tracer.

andrewlock · 2025-02-04T12:32:18Z

tracer/build/_build/Build.Shared.Steps.cs

-            // The profiler has a different minimum glibc version to the tracer.
-            // The _overall_ minimum is the highest of the two, but as we don't
-            // currently enable the profiler on ARM64, we take the .NET runtime's minimum
-            // glibc as our actual minimum in practice. Before we can enable the profiler
-            // on arm64 we must first ensure we bring this glibc version down to 2.23.
-            //


Similar to elsewhere, I think we actually need to expand this so that we check the glibc requirements for all the libraries we load, including libdatadog (and potentially libddwaf, though I think that is compiled like the native loader?)

ganeshnj

Thanks for making these changes.

ganeshnj · 2025-02-04T12:57:48Z

profiler/Directory.Build.targets

@@ -12,4 +12,40 @@
      <AdditionalDependencies>$(LibDatadogDependencies);%(AdditionalDependencies)</AdditionalDependencies>
    </Link>
  </ItemDefinitionGroup>
+
+  <PropertyGroup>


❓
Shouldn't this be at the top level for both profiler and tracer?

For example if I'm running Datadog.Trace.Integration tests, we would like to copy right platform binaries in the target directory.

You are right, but at this point it's only profiler, so I prefer scoping this change to profiler and coming back at it when integrating this the tracer

datadog-ddstaging · 2025-02-10T08:43:39Z

Datadog Report

Branch report: gleocadie/profiler-use-libdatadog-dyn
Commit report: 683abbc
Test service: dd-trace-dotnet

✅ 0 Failed, 230569 Passed, 2009 Skipped, 13h 34m 43.46s Total Time

datadog-datadog-prod-us1 · 2025-02-27T11:14:45Z

Datadog Report

All test runs 50ca661 🔗

✅ 2 Total Test Services: 0 Failed, 2 Passed

Test Services

Service Name	Failed	Known Flaky	New Flaky	Passed	Skipped	Total Time	Test Service View
`dd-trace-dotnet`	0	0	0	249896	2957	22h 20m 43.82s	Link
`exploration_tests`	0	0	0	22085	3	2m 8.42s	Link

andrewlock

Thanks! :blindfold: 🤞 😄

andrewlock · 2025-03-14T13:52:23Z

profiler/test/Datadog.Profiler.Native.Tests/Datadog.Profiler.Native.Tests.vcxproj.filters

-    <ClInclude Include="ThreadsCpuManagerHelper.h">
-      <Filter>Helpers</Filter>
-    </ClInclude>


Was this intentional? 🤔

not that I remember 🤔
I'll check thx

andrewlock · 2025-03-14T13:53:57Z

shared/src/msi-installer/shared/Files.wxs

+    <ComponentGroup Id="Shared.Files.Libdatadog.64" Directory="INSTALLFOLDER.win_x64">
+      <Component Win64="yes">
+        <File Id="libdatadog"
+              Source="$(var.MonitoringHomeDirectory)\win-x64\datadog_profiling_ffi.dll"


Any progress on that renaming? And to clarify, is this only an ffi for the profiling functionality? Will we have additional dlls for other ffi (for data pipelin etc)

…ead (#6301)

github-actions bot added the area:profiler Issues related to the continous-profiler label Nov 18, 2024

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 2 times, most recently from 6211ed7 to 11e14e2 Compare November 18, 2024 19:00

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 2 times, most recently from cedf2e0 to 59958ab Compare November 21, 2024 19:33

gleocadie changed the title ~~[Profiler] Change profiler to use the sofile instead~~ [Profiler] Change profiler to use the libdatadog dynamic library instead Nov 22, 2024

gleocadie marked this pull request as ready for review November 22, 2024 14:21

gleocadie requested review from a team as code owners November 22, 2024 14:21

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch from 968a5f1 to 8e19154 Compare November 22, 2024 14:41

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 4 times, most recently from 6b2ff48 to 279fa6b Compare January 17, 2025 09:47

chrisnas approved these changes Feb 3, 2025

View reviewed changes

andrewlock reviewed Feb 4, 2025

View reviewed changes

ganeshnj reviewed Feb 4, 2025

View reviewed changes

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 2 times, most recently from 4e22760 to dded8fd Compare February 10, 2025 08:42

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 2 times, most recently from c3d9e7a to 683abbc Compare February 10, 2025 14:44

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch 2 times, most recently from 1307ce2 to 71d81a6 Compare February 27, 2025 10:51

gleocadie requested a review from a team as a code owner February 27, 2025 10:51

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch from 71d81a6 to 5b4dc22 Compare February 27, 2025 11:25

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch from 5b4dc22 to 649a8ad Compare March 12, 2025 17:44

andrewlock approved these changes Mar 14, 2025

View reviewed changes

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch from 649a8ad to 7f75212 Compare March 17, 2025 10:54

gleocadie added 14 commits March 18, 2025 08:07

Change profiler to use the sofile instead

1430a22

Windows dyn load libdatadog

a873ee9

Bump libdatadog to 14.2.0

a47e2bb

Update MSI

fa47cc9

Publish libdatadog binaries

aa5b214

Fix MSI

ddba078

Fix glibc check

2d6c811

Debug crash in libdatadog

56bf7e5

Rebase and adjust

45d4b63

Fix Windows buid job

dd9c155

Clean up a bit

c6116d0

Fix windows build

5ee73aa

Address PR comment

841570d

Check dependencies per native libs

50ca661

gleocadie force-pushed the gleocadie/profiler-use-libdatadog-dyn branch from 7f75212 to 50ca661 Compare March 18, 2025 07:28

gleocadie merged commit 27b6beb into master Mar 18, 2025
135 of 138 checks passed

gleocadie deleted the gleocadie/profiler-use-libdatadog-dyn branch March 18, 2025 09:27

github-actions bot added this to the vNext-v3 milestone Mar 18, 2025

ddyurchenko pushed a commit that referenced this pull request Mar 31, 2025

[Profiler] Change profiler to use the libdatadog dynamic library inst…

babe035

…ead (#6301)

		<TopLevelDeployDirectoryBase Condition="'$(DeployToMonitoringHome)' == 'True'">$(EnlistmentRoot)\shared\bin\monitoring-home</TopLevelDeployDirectoryBase>
		<TopLevelDeployDirectoryBase Condition="'$(DeployToMonitoringHome)' != 'True'">$(BuildOutputRoot)\DDProf-Deploy</TopLevelDeployDirectoryBase>

[Profiler] Change profiler to use the libdatadog dynamic library instead #6301

[Profiler] Change profiler to use the libdatadog dynamic library instead #6301

Uh oh!

Conversation

gleocadie commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of changes

Reason for change

Implementation details

Test coverage

Other details

Uh oh!

datadog-ddstaging bot commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Datadog Report

Uh oh!

andrewlock commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Execution-Time Benchmarks Report ⏱️

Uh oh!

andrewlock commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks Report for tracer 🐌

Benchmark details

Raw results

Raw results

Raw results

More allocations ⚠️ in #6301

Raw results

Slower ⚠️ in #6301

Raw results

Faster 🎉 in #6301

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Faster 🎉 in #6301

Raw results

Raw results

Uh oh!

chrisnas left a comment

Choose a reason for hiding this comment

Uh oh!

andrewlock left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ganeshnj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

gleocadie commented Nov 18, 2024 •

edited

Loading

datadog-ddstaging bot commented Nov 18, 2024 •

edited

Loading

andrewlock commented Nov 18, 2024 •

edited

Loading

andrewlock commented Nov 18, 2024 •

edited

Loading

datadog-ddstaging bot commented Feb 10, 2025 •

edited

Loading

datadog-datadog-prod-us1 bot commented Feb 27, 2025 •

edited

Loading