The fixed batches of 1024 addresses could overflow the platform's command-line limit (`La ligne de commande est trop longue.` from cmd.exe on Windows, whose limit is ~8191 characters). Build each batch by appending addresses until a length budget is reached instead. A single conservative budget of 8000 stays under the smallest limit on every platform, and keeps batches in the same ballpark as before (several hundred addresses per invocation).
The new `-R` option of tracy-update sets every callstack frame back to `[unresolved]` / `[unknown]`. Since failed lookups leave frames untouched and the image-relative offset in `symAddr` survives patching, this makes it possible to chain several resolution passes over the same capture, each with different `-p` path substitutions (e.g. one pass per symbol directory).
The addr2line backend of tracy-update now builds on every platform, including Windows, and can be pointed at any addr2line-compatible executable:
- `-a`: path to a custom symbol resolution tool (e.g. `llvm-addr2line` or a cross-compilation toolchain's `addr2line`). Works on all platforms and takes precedence over the platform default (DbgHelp on Windows, the `addr2line` found in `PATH` elsewhere). Path-like values are validated up front so a wrong path fails with an actionable message instead of a cryptic, localized shell error.
- `-A`: extra arguments passed verbatim to the tool, e.g. `--relative-address` so `llvm-addr2line`/`llvm-symbolizer` accept the image-relative offsets Tracy records for images with a non-zero preferred base (PE, Mach-O).
- `-v`: verbose output while patching symbols.
OfflineSymbolResolverDbgHelper.cpp uses IMAGEHLP_LINE but
SymGetLineFromAddr64 expects IMAGEHLP_LINE64. On 64-bit Windows these are typedef'd to the same thing, but on 32-bit they're different.
addr2line starts failing when given too many addresses to resolve.
Batching per 1024 addresses allows not only to see progress but also fixes resolution for images with high number of addresses to resolve.
Escaping is also required when image paths have spaces for example.
PPQSort is supposedly quite fast: https://github.com/GabTux/PPQSort
More importantly, it does not depend on TBB fuckery, so there's no longer
a need to link with an external library that people may or may not have.
The NO_PARALLEL_STL option is out, as it was provided solely to deal with
TBB being not available. Sequential sorting is still used on emscripten.
From the project() CMake documentation:
> If enabling ASM, list it last so that CMake can check whether compilers for other languages like C work for assembly too.
Executing the "make db" will run the build process of the selected tool or
library through the bear wrapper (which has to be available in the system),
which will record the compilation parameters of each source file. This
database can be then used by VS Code to set the proper defines and find all
the required includes.
Note that database building is performed in context of the specific tool or
library. Not all tools have the same set of flags.
