The function is about to dispatch between rpmalloc and a pluggable allocator hook, so the rpmalloc-specific name no longer fits. Pure rename plus a small consequence: the SymbolWorker call site no longer needs the TRACY_USE_RPMALLOC guard, since the no-op static-inline fallback in TracyAlloc.hpp makes InitAllocator() safe to call unconditionally.
After investigating (downloading and installing) all publicly available SDKs at https://learn.microsoft.com/en-us/windows/apps/windows-sdk/downloads-archive I concluded the `TRACEHANDLE` deprecation started in `10.0.26100`.
This defines `PROCESSTRACE_HANDLE` and `CONTROLTRACE_ID` as done by the SDK when using older versions. Using `WDK_NTDDI_VERSION` (and not `NTDDI_VERSION` which may change based on `_WIN32_WINNT` or user input seems to be the most reliable way to do it. While it says "WDK" it's been part of the SDK in `shared\sdkddkver.h`. Note it doesn't work for MinGW because it updates half of its sdk files for some reason.
Tested with both 10.0.26100 and 10.0.22621.0 which is the last one I found without the new types.
Also changes CONTROLTRACE_ID to ULONG64 on mingw which is correct (type used by `TRACEHANDLE` too in mingw fe2763863a/mingw-w64-headers/include/evntrace.h (L60) )
perf_event_open(pid>0, cpu>=0) binds to a single task, so the previous
setup only sampled the target's main thread. In monitor mode, enumerate
/proc/<pid>/task/ and open one per-task event per existing thread with
cpu=-1; inherit=1 then covers every descendant. Self-profiling behavior
is preserved byte-for-byte: the iter list becomes (currentPid, i) for
each CPU, exactly what the old code did inline.
This is to be consistent with what libtracefs does: 6fad6a14ba/src/tracefs-utils.c (L104)
In theory one may mount tracefs with another name, though unlikely.
This forces to (re)use frequency values as input, which may be changed by the platform code later on. This way we have a single "source of truth" for sample freq.
Also removed the Win32 `GetSamplingInterval` which was a wrapper above `GetSamplingPeriod` but its value would be divided again anyway.
Ideally I think we might want to have TRACY_HW_TIMER mean only TSC/CNTVCT, and define TRACY_TIMER_FALLBACK for platforms that don't have them or have a special case such as iOS.
But for now, keep the same behaviour.
`sched_wakeup` notifies about the kernel saying it will be waking up the thread, not the reason for the actual wakeup. This only allows to measure the scheduling latency, not the full wake up latency.
Instead, use `sched_waking` which is triggered on the ring of the CPU and thread responsible for the wakeup. `target_cpu` contains the cpu on which the thread will be woken up.
This PR does the following things:
- Allow to lock the highlighted thread using left mouse click or lane popup menu
- Add more descriptions for wait reasons in View::DecodeContextSwitchReason
- Stores the Wakeup CPU so that we may display it in the CPU data view
- `QueueThreadWakeup` now contains cpu and adjust info (currently unused). Fits in the padding, no struct size change.
- `QueueContextSwitch` now also contains thread priorities information (windows+linux) and CState (windows), but currently unused by the profiler. Fits in the padding, no struct size change.
- Fixes Linux `EventWakeup` which tries to remove PERF_SAMPLE_CALLCHAIN on the wrong member. Set the whole `perf_event_attr` explicitely instead.
- Fixes Windows ReadyThread event being dropped if triggered before the thread switches out (this is confirmed to be normal behaviour, probably due to thread being switched out but context switch actually happening later)
- Bumps tracy file version and protocol versions
