#1326
Pull Requests/wolfpld/tracy/#1326

[RFC] Start splitting TracyCallstack.cpp

DraftLectemwants to merge intofrom
2 commits3 files changed+802-735

Main objective of starting this refactoring is to have some kind of SymbolResolver abstraction with a clean interface. This will let us switch between implementations more easily, and also reuse them in tools and server, notably for offline resolution. This should also help for non-pdb symbols support on Windows (MinGW mostly?) by allowing libbacktrace to be used as fallback to DbgHelp (I'm not sure I want to do this, but in any case a cleaner abstraction should help).

Activity

3
C
Start splitting TracyCallstack.cpp
bda84ff
C
Move DbgHelp.dll related function to TracySymbolsDbgHelp.cpp
9bf52f9
slomp5mo ago

About the SymbolResolver, my thoughts:

  • Have a simple struct SymbolResolver capable of holding the necessary state for online/offline symbol resolution
  • This struct SymbolResolver should be per-platform (we could then expose it to the rest of the SysTrace/Callstack code as using SymbolResolver = SymbolResolverWindows, for example)
  • Have a single SymbolInfo Resolve(SymbolResolver, Address) API; when you call it, you get all the information available for the given address (symbol name, line information, including an array of inline frames name/line info, if any)

We should also consider having a "batch" mode, where you pass an address and a size/range, and it resolves all addresses in that range (you'd get a SymbolInfo array out of it). We should also try to prime these APIs to be called concurrently/in-parallel when possible.

This pull request is a draft

Merging is unavailable until it is marked ready for review.