Loading symbol files

[440bx]

Hello,

For the time being the following question is mostly to satisfy my curiosity.

Presume a utility exists that creates DWARF symbol information for Windows executables (including dlls) created with compilers that do not generate DWARF symbols for them, e.g, all Windows system dlls and programs distributed with Windows, e.g, ntdll.dll, kernelbase, Calc, WordPad, etc.

The problem is those module do not have a "gnu_debuglink" letting the debugger know there is an external symbol file and its location.

The question is: how much work would be required to add the capability of declaring the existence of DWARF symbol files for some system code (Windows dlls and programs in the Windows directories , i.e, system32, syswow64, etc) ?

At this time, the idea would be to create a ".dbg" file stored in a configurable directory (a symbol cache) where the file name is the GUID stored in the debug directory (which, most if not all, Windows dlls/programs have.)  Therefore, once the IDE knows the directory, it can look for the GUID and look for a file named <guid>.dbg in that directory and load DWARF symbols for the module if available (not available would not be an error.)

Does the above sound reasonable and feasible without requiring an inordinate amount of work ?

Thank you.

[Martin_fr]

I haven't looked at how to retrieve the GUID, but assume it is trivial.
The loading should be trivial too.

The "most" work is passing the config around. That is just labour though, not skill.

The config would come From LazDebuggerFp, it then needs to be passed through several instances, to get to the loader. But so does the filename.

[440bx]

I haven't looked at how to retrieve the GUID, but assume it is trivial.

Yes, that part is easy.  It's in the Debug Directory, debug type: codeview (which seems to always be the first descriptor.)

The "most" work is passing the config around. That is just labour though, not skill.

The config would come From LazDebuggerFp, it then needs to be passed through several instances, to get to the loader. But so does the filename.

Great.  It's good to know there are no real problems to implement it, just, as expected, some work. 

Thank you.  I needed to know that.