search

rainers / cv2pdb

converter of DMD CodeView/DWARF debug information to PDB files
Artistic License 2.0
472 stars 109 forks source link

cv2pdb can't find the debug info of mscoff executables #14

Closed calexHG closed 8 years ago

calexHG commented 8 years ago

I've been unable to debug my mscoff-built project, so I did some experimentation with a dummy project to see what was failing here.

I just tried all 6 permutations of [ldc2/dmd -m32mscoff] and [-g/-gc/no debug info], and also one control run without -m32mscoff.

Comparing the binary output between the builds, both compilers are definitely producing extra output when debug info is enabled (I figured one possibility was that the compilers simply didn't support embedding debug info into 32-bit mscoff but it seems that they do), but cv2pdb always reports no debug info found.

E:\code\dlang\temp\mscoff_tests>cv2pdb.exe coff_test-debugInfoC.exe coff_test-debugInfoC.pdb.exe coff_test-debugInfoC.exe: no codeview debug entries found

Is mscoff unsupported? : 0

calexHG commented 8 years ago

PS: Thanks for maintaining this absolutely necessary D utility.

calexHG commented 8 years ago

Fortunately, when I'm on Windows I've not had to debug in anything other than full IDE's. Nonetheless, I just tried Windbg to resolve this situation. The Windbg bundled with DMD 2.070.2 similarly reports No Symbolic Info for Debugee when stepping into the 32-bit COFF image that DMD was instructed to embed C-style debug info into (via -gc).

Any idea what's going wrong here?

rainers commented 8 years ago

If you build with dmd -m32mscoff or dmd -m64 or with a recent version of ldc, the generated object files contain debug info in a format that allows the MS linker to generate an appropriate PDB file that should work with standard debuggers. So you don't need to run cv2pdb on these executables, it is used to convert debug information generated with dmd -m32.

There are a few issues, though:

The Windbg bundled with DMD 2.070.2

IMO the version of windbg distributed with dmd must be considered a joke.

calexHG commented 8 years ago

Ah! Sorry, executable formats are one of my happily accepted blackboxes ;] So I hadn't recognized that this would be redundant.

Soon enough I'll build up enough willpower to try navigating the D obstacle course again, confirm what you explained and close out this issue from your tracker. (I hope it doesn't bother you if I leave this open in the meantime.)

sighs I must admit I'm losing my steam. Unlike in my earlier years, I don't have the same patience anymore. And despite the 2.x.y versioning milestone, D's proving to be incredibly rough around the edges.

I'll get back to you soon.

calexHG commented 8 years ago

There are a few issues, though:

  • ldc only emits line number info, no debug info to inspect variables. This is being worked on by the LLVM people.

Well, if it consistently emits correct context & line number info, that's would at least be something. So far none of the solutions I've tried are even close to being dependably usable. Is the current lack of non-buggy debugging just a Windows situation at the moment, as far as you know?

  • with dmd generated debug info type names containing '.' confuse the Visual Studio debugger, so option -gc makes dmd replace it with '@'. This is not necessary when using Visual D and the mago debug engine.

Wait, is Mago supposed to be working? O_O It never has— not from the beginning when I installed VisualD a month or two ago— so, given the disclaimers on the VD page, its inheritance into VD from a dead project, and the seemingly obvious nature of how it doesn't work, I assumed it was simply known to be aged and no longer working. If it's actually supposed to be working, shoulders sagging I suppose that's another bug I'll have to get around to filing. sighs Although, there's really nothing to file. It just flat out never never kicks in and starts recognizing any debug info-- not even with an untinkered-with default VD console-mode DMD "Hello world" project. (Sorry, the nature of it was so obvious, it seemed impossible that it was supposed to be working.)

IMO the version of windbg distributed with dmd must be considered a joke.

Oh? Thanks for mentioning this. Thanks to your comment, I'm now on the current MS release. Indeed, it's less ancient-looking and cobbled-together as that old version. Is there anything missing from it, out-of-the-box, WRT to D-compatibility, that the bundled version has?

IIRC, the dlang.org page on debugging warned that not using the version bundled with DMD might not work, and also implied Ddbg was no longer working, so I would never have thought to look for a different version.

Argh, by know I've written enough on all the satellite issues, there's not time to report on what happened when trying your suggestion. Work to do.

sighs I'll be back.

calexHG commented 8 years ago

Meh. The previous post lacks context without what I intended to write. So, a quasi-quick summary...

The Windbg bundled with DMD 2.070.2 similarly reports No Symbolic Info for Debugee when stepping into the 32-bit COFF image that DMD was instructed to embed C-style debug info into (via -gc).

Whatever it was, I got the dummy project to get its symbols recognized by the newly installed Windbg.

However the real project still wasn't getting recognized. In summary, fast-forward through the search for differences and it seems that no longer including the stack size specification (/STACK:8388608) in the flags passed to the linker finally enabled the symbols to get recognized. Any insights?

But... the context info (what function scope we're in) & line number info is wrong for parts of code I'm interested in debugging, requiring using the disassembly view anyway (but at least with proper symbol names embedded into the view). Any insights on this?

If I had a dime for every workaround...

Lightning round of satellite issues that swallowed my time & energy but that I can't elaborate on right now:

Anyway, this clearly beyond the scope of cv2pdb now.. Thanks. Closing the issue and working around/battling against D some more when I have time to.

Thank for you for your tireless contributions to the community.

-C.

rainers commented 8 years ago

Sorry to hear you had such a bad debugger experience. It does work for me reasonably well (including mago), but I guess I'm just used to the quirks.

it seems that no longer including the stack size specification (/STACK:8388608) in the flags passed to the linker finally enabled the symbols to get recognized. Any insights?

Never heard this problem. If you use dmd for linking, enabling verbose compilation shows the linker command line, maybe there is something fishy about it. In Visual D, you find it in the build batches in the output direcotry.

But... the context info (what function scope we're in) & line number info is wrong for parts of code I'm interested in debugging, requiring using the disassembly view anyway (but at least with proper symbol names embedded into the view). Any insights on this?

That's something I can confirm: line numbers are sometimes lost (more often in templated code AFAICT), with LDC making it worse because it creates bad entries that are more confusing than dmd's omissions. There are already bugzilla entries for this, but unfortunately, reducing the code to manageable and debuggable size often makes the problem disappear.

calexHG commented 8 years ago

Sorry to hear you had such a bad debugger experience.

Thanks. And message tone can often get misinterpreted on the internet so hopefully you know that I'm not sarcastic when I thank you for you contributions...

I've been privately hacking on the internals of several core D projects in the past month during my foray into this wonderful but not-yet-ready-for-primetime language, and the prior pull requests and the like all tell the same story: D needs more people like you.

Your contributions in both code and in advice towards making the experience on Windows (the predominant platform, in case people have forgotten) work properly are crucial.

D needs a whole lot more if it is ever to be considered release quality —and thus acceptably-usable for people that aren't interested in having to muck about (IE. the rest of the programming audience that it's missing)— but it won't get there if it doesn't receive contributions like yours.

So thanks.

It does work for me reasonably well (including mago)

You have me curious now. I’ll step over to the mago repository/issue tracker when I get a chance.

Take care, C.