Halide icon indicating copy to clipboard operation
Halide copied to clipboard

Debug symbols for LLVM-generated runtime objects

Open slomp opened this issue 7 months ago • 3 comments

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 avatar May 23 '25 20:05 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?

slomp avatar May 23 '25 20:05 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).

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?

mcourteaux avatar May 23 '25 21:05 mcourteaux

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 avatar May 23 '25 21:05 slomp

@slomp does #8703 help you here?

mcourteaux avatar Aug 02 '25 17:08 mcourteaux

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).

slomp avatar Aug 02 '25 17:08 slomp