Debug symbols for LLVM-generated runtime objects
Consider the following:
std::map<Halide::OutputFileType, std::string> outputs;
outputs[Halide::OutputFileType::object] = ...;
Halide::compile_standalone_runtime(outputs, target)
How do we obtain function symbols from the generated Halide/LLVM object file? How can we produce debug/symbol information compatible with Windows PDB?
If we still had MinGW support, we could emit a clang/gcc-like object with DWARF, and use cv2pdb to get a pdb out of it (and some MinGW tooling to convert the object itself to Windows COFF).
Other than that, we could have an output type to generate a runtime.ll file, and then use clang-cl later to produce COFF object and the associated PDB file.
What else?
If we still had MinGW support, we could emit a clang/gcc-like object with DWARF, and use cv2pdb to get a pdb out of it (and some MinGW tooling to convert the object itself to Windows COFF).
Would the debug information from a MinGW build map correctly to a Windows-native Halide runtime? That would surprise me. Those are two different compilers?
Would the debug information from a MinGW build map correctly to a Windows-native Halide runtime?
If you go through a converter, like the cv2pdb I mentioned above, then technically yes. AFAIK, by default, MinGW produces COFF objects on Windows, but the debug information is DWARF. cv2pdb gets the dwarf data embedded into the object/lib/exe and produces a PDB file that Windows and MSVC can use to lookup symbols and such.
@slomp does #8703 help you here?
I think we have two spaces to consider here:
- the LLVM-generated Halide algorithm+schedule code (this is what your PR #8703 addresses)
- the Halide runtime
And we also have two somewhat orthogonal issues:
- stack unwinding (that's what your PR #8703 will hopefully solve!)
- debug symbol resolution
A bit of context: for the D3D12 runtime, in the early days, I had to implement some assembly stubs to translate from the GNU ABI to the Windows ABI (https://github.com/halide/Halide/pull/2755/commits/fdc12e7791dd10c09926668e1b00cfd340f0d269). Later we solved this issue by passing the proper platform ABI (windows) to the corresponding triplets (https://github.com/halide/Halide/pull/5217).
However, as far as debug information goes, these modules are not compiled with clang-cl, so pdb files are never generated. The debug information remais DWARF-ish. Even with proper stack unwinding, it's unlikely debuggers/profilers will be able to resolve debug symbols on Windows if they rely on the Windows dbghelp.lib (the Sym* API).