Skip to content

Refactoring debug symbol resolving process on Windows#1346

Open
slomp wants to merge 8 commits into
wolfpld:masterfrom
slomp:slomp/win-dbghelp-overhaul
Open

Refactoring debug symbol resolving process on Windows#1346
slomp wants to merge 8 commits into
wolfpld:masterfrom
slomp:slomp/win-dbghelp-overhaul

Conversation

@slomp
Copy link
Copy Markdown
Collaborator

@slomp slomp commented Apr 22, 2026

Present:

  • adding wrappers around the DbgHelp API to intercept/report errors
  • tracking the "symbol database type" of each module to cull unnecessary work
  • scoped lock for DBGHELP_LOCK/UNLOCK
  • adding TRACY_SYMBOL_PATH to _NT_SYMBOL_PATH for SymSrv.dll
  • decoupling "outer" frame resolve logic from inlined frame resolve logic

Planned for a future PR:

  • resolve symbols via DIA (SymGetDiaSession()) whenever possible
  • request "bulk" code symbol resolving from cs_disasm() loop

@slomp slomp marked this pull request as ready for review April 23, 2026 22:05
@slomp slomp force-pushed the slomp/win-dbghelp-overhaul branch from bd3aa9a to 08d9a6b Compare April 25, 2026 00:41
@slomp slomp requested a review from Lectem April 25, 2026 16:51
@slomp slomp force-pushed the slomp/win-dbghelp-overhaul branch from 08d9a6b to 207a7ab Compare April 28, 2026 22:08
@slomp slomp force-pushed the slomp/win-dbghelp-overhaul branch from bdb1508 to 59bf76e Compare May 9, 2026 20:40
if( code != ERROR_SUCCESS )
{
char msg [512] = {};
const char* modName = ModuleName ? ModuleName : (ImageName ? ImageName : "[NULL]");
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use ImageName first for logging. Even though ModuleName is the "Friendly name", it is sometimes necessary to differentiate two dlls named the same way by their path (yes, it's possible!).

return 0;
#endif
using SymAddrIncludeInlineTraceProc = decltype(TracySymAddrIncludeInlineTrace)(__stdcall*);
static auto _SymAddrIncludeInlineTrace = (SymAddrIncludeInlineTraceProc)GetProcAddress(GetModuleHandleA("dbghelp.dll"), "SymAddrIncludeInlineTrace");
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I like having deferred loading of dll procs each in their own function. I'd rather keep this in the init function if only so that we can log all loading failures at the same place, and know the list of things we depend on in one place.

{
static constexpr size_t MaxNameSize = 8*1024;
SYMBOL_INFO info;
char buf [MaxNameSize]; // must follow SYMBOL_INFO
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we pack to avoid padding here?

char* m_name = nullptr;
char* m_path = nullptr;

#if TRACY_HAS_CALLSTACK == 1
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I'll probably turn this into a BuildInfo (buildid/pdb info, etc) member later

{
const char* name;
uint64_t baseAddr;
#if TRACY_HAS_CALLSTACK == 1
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one (I'm on mobile right now), but isn't this Windows only already?


return { cb_data, 1, moduleNameAndBaseAddress.name };
DbgHelpInline inln;
int inlineNum = DbgHelpTraceInline( inln, ptr );
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It bothers me a bit that the lock is now inside the wrappers, it means we're going to lock/unlock it for each call where before we would just lock unlock once.

namespace tracy
{

struct ImageEntry
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I'll probably move it back here when adding build info, cause I'll need it to be part of the interface if we want offline resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants