[clang] [compiler-rt] [XRay] Add support for instrumentation of DSOs on x86_64 (PR #90959)

[Sebastian Kreutzer via llvm-commits]

================
@@ -0,0 +1,62 @@
+//===-- xray_init.cpp -------------------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file is a part of XRay, a dynamic runtime instrumentation system.
+//
+// XRay initialisation logic for DSOs.
+//===----------------------------------------------------------------------===//
+
+#include "sanitizer_common/sanitizer_atomic.h"
+#include "xray_defs.h"
+#include "xray_flags.h"
+#include "xray_interface_internal.h"
+
+using namespace __sanitizer;
+
+extern "C" {
+extern const XRaySledEntry __start_xray_instr_map[] __attribute__((weak))
+__attribute__((visibility("hidden")));
+extern const XRaySledEntry __stop_xray_instr_map[] __attribute__((weak))
+__attribute__((visibility("hidden")));
+extern const XRayFunctionSledIndex __start_xray_fn_idx[] __attribute__((weak))
+__attribute__((visibility("hidden")));
+extern const XRayFunctionSledIndex __stop_xray_fn_idx[] __attribute__((weak))
+__attribute__((visibility("hidden")));
----------------
sebastiankreutzer wrote:

The `{start,stop}_xray_instr_map`  symbols are resolved to the begin and end addresses of the `xray_instr_map` ELF section. Same for the `xray_fn_idx` section.

They are using weak linkage so that if, for whatever reason, these sections don't exist, the linker will not fail.
In this case, the XRay runtime will simply not register any patchable sleds. 
I adopted this behavior from the existing `xray_init.cpp`.

Because they are using hidden visibility and each DSO has their own `xray_dso_init.cpp` statically linked, these symbols should resolve correctly regardless of `RTLD_GLOBAL`/`RTLD_GLOBAL`. 

I therefore think that the situation you describe should be handled correctly. 
I will add tests to verify this.

https://github.com/llvm/llvm-project/pull/90959