Debug symbols for LLVM-generated runtime objects

[slomp]

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?

[slomp]

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?

[mcourteaux]

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?

[slomp]

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.

[mcourteaux]

@slomp does #8703 help you here?

[slomp]

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 (fdc12e7). Later we solved this issue by passing the proper platform ABI (windows) to the corresponding triplets (#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).