[debuginfo][codeview] avoid using line zero artificial location for t…

[hyp]

…raps when emitting codeview

This fixes an issue where the debug locations for Swift traps were dropped in the produced PDB files, as they were pointing to line 0

I validated this on a sample project using WinDbgx, which can now correctly trap on the same line in multiple places.

Before:

After:

[hyp]

@swift-ci please test

[hyp]

@swift-ci please test

[adrian-prantl]

Long-term, I wonder if we should investigate whether we couldn't produce both CodeView and DWARF at the same time, so users of WinDbg see something, while users of LLDB get the full experience.

[adrian-prantl]

This will likely result in larger debug info, since the abstract origin of the inlined function can no longer be uniqued but that's the kind of tradeoff you'll need to make.

[hyp]

Yep, I agree. I think the win in crash investigation is worth it here.

[hyp]

Long-term, I wonder if we should investigate whether we couldn't produce both CodeView and DWARF at the same time, so users of WinDbg see something, while users of LLDB get the full experience.

What specifically are you thinking of? making the frontend emit IR that's compatible with both DWARF and CodeView, and then lowering it to something that emits both DWARF and CodeView files in LLVM?

[hyp]

@swift-ci please test

[adrian-prantl]

Long-term, I wonder if we should investigate whether we couldn't produce both CodeView and DWARF at the same time, so users of WinDbg see something, while users of LLDB get the full experience.

What specifically are you thinking of? making the frontend emit IR that's compatible with both DWARF and CodeView, and then lowering it to something that emits both DWARF and CodeView files in LLVM?

Yes something along those lines. Of course we'd then need to make the kinds of decisions done in this patch in the backend instead.