Linux exposes time_zero/time_mult/time_shift on the perf_event mmap
page for converting sample timestamps back to TSC cycles, gated by
cap_user_time_zero. That flag only states the conversion math is
valid; on Ryzen the kernel can leave it set while TSC silently drifts
between cores, before the clocksource watchdog catches it. We've had
user reports of this surfacing as garbage timestamps in traces.
CheckLinuxPerfTscConsistency() first looks at the current clocksource
in sysfs, then opens a dummy PERF_COUNT_SW_DUMMY event and verifies
that a PR_SET_NAME-triggered PERF_RECORD_COMM timestamp inverts back
into the rdtsc-sandwiched window with ~1 ms of slack. Modeled on
tools/perf/tests/perf-time-to-tsc.c.
Wired into CheckHardwareSupportsInvariantTSC() so a failing probe
calls InitFailure in non-fallback builds and routes GetTime() to
clock_gettime in TRACY_TIMER_FALLBACK builds. Inconclusive cases
(perf blocked, no COMM record, etc) return true to avoid penalising
sandboxed environments. Gated on TRACY_HAS_SYSTEM_TRACING so we only
probe when Tracy would actually open perf events.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace `#ifdef BSD` (which requires including `<sys/param.h>` first) with explicit checks for `__FreeBSD__`, `__NetBSD__`, `__OpenBSD__` and `__DragonFly__`, matching how these BSDs are already enumerated elsewhere in the codebase (OS name strings, thread id helpers, etc.).
This also avoids leaking the `sys/param.h` requirement through public headers (`TracySysTime.hpp`, `TracyCallstack.h`), where consumers would otherwise need it to correctly see `TRACY_HAS_SYSTIME` / `TRACY_HAS_CALLSTACK`.
`libbacktrace/config.h` is left as-is — it's third-party and only included from .c files where the `BSD` macro can still be picked up locally.
Note: for `setsockopt( m_sock, IPPROTO_IPV6, IPV6_V6ONLY, (const char*)&val, sizeof( val ) );` I added `__APPLE__` too since this was the only place where it was not checked explicitely.
We redirect GetProfiler() (most likely used by any project consuming tracy, since it's used by `tracy::ScopedZone`) to its implementation which now has a different function name based on the macros that can impact ABI (and enabled/disabled).
That way, when linking with mismatched defines you'd get an error such as
> main.obj : error LNK2019: unresolved external symbol "int __cdecl GetProfiler_CFG_E0_OD0_DI0_ML0_F0_DHT0_TF0(void)" (?GetProfiler_CFG_E0_OD0_DI0_ML0_F0_DHT0_TF0@@YAHXZ) referenced in function "int __cdecl GetProfiler(void)" (?GetProfiler@@YAHXZ)
Or
>[build] /usr/bin/ld: CMakeFiles/app.dir/main.cpp.o: in function `GetProfiler()':
[build] /..../TracyProfiler.hpp:143: undefined reference to `GetProfiler_CFG_E1_OD0_DI0_ML0_F0_DHT0_TF0()'
Reason for going with acronym+0/1 instead of just acronym when enabled is for us to be able to tell users easily which define is wrong by just looking at the error if needed.
The only thing we don't really detect is user not having TRACY_ENABLE but tracy having been built with it. This is because macros become noops in that case, with no reference to `GetProfiler`.
There may be a way to do it by introducing a local variable into each TU, but I don't really like that idea.
We could also add pragma detect mismatch for a more user-friendly error on windows (https://learn.microsoft.com/en-us/cpp/preprocessor/detect-mismatch?view=msvc-170).
This also replaces `___tracy_emit_message*` by `___tracy_emit_logString`.
The `TracyCMessage*` defines no long include the `;`, which may be a breaking change even though we did already require semi-colon since 0.9.0. See #493 and #592
There are two changes to the protocol:
- `QueueMessageLiteral*` were changed and what used to be addresses are now addresses+metadata
- Other messages now send `QueueMessage*Metadata` with added metadata.
This will later be used to store and transmit message sources, level, etc.
Atomic variables need to be initialize with direct-initialization
instead of copy-initialization lest the compilation fails complaining
about missing constructor for the atomic type.
In Profiler::DequeueSerial if AppendData fails part way through m_serialDequeue then the elements could be freed again in Profiler::ClearSerial, which leads to memory corruption in rpmalloc.
This value is not used for anything, it was just a number displayed in
the UI without much meaning to anyone.
Operations on the queue during early init may not work correctly, stopping
some programs from running past the calibration loop.
