www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The dmd backend should generate .pdb files for visual studio.

reply 12345swordy <alexanderheistermann gmail.com> writes:
I think it time for dmd to do so, as the backend is currently 
opensource. The fine folks at llvm created documentation for the 
PDB file.
https://llvm.org/docs/PDB/index.html
By doing so, the visual studio debugging experience would be much 
smoother as the debugging information is now generated for types 
correctly, without having to rely on converting the dwarf 
information into a .pdb file.

Anyone else interested in generating .pdb files?

-Alex
Feb 20
parent reply bachmeier <no spam.net> writes:
On Saturday, 20 February 2021 at 16:12:52 UTC, 12345swordy wrote:
 I think it time for dmd to do so, as the backend is currently 
 opensource. The fine folks at llvm created documentation for 
 the PDB file.
 https://llvm.org/docs/PDB/index.html
 By doing so, the visual studio debugging experience would be 
 much smoother as the debugging information is now generated for 
 types correctly, without having to rely on converting the dwarf 
 information into a .pdb file.

 Anyone else interested in generating .pdb files?

 -Alex
Doesn't it already do that? https://dlang.org/windbg.html (Maybe I'm not understanding.)
Feb 20
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 20 February 2021 at 16:48:43 UTC, bachmeier wrote:
 Doesn't it already do that? https://dlang.org/windbg.html

 (Maybe I'm not understanding.)
Read this line here: "The debug information format used is an ancient version of CodeView that is only partially supported by more recent debuggers." -Alex
Feb 20
parent reply kinke <noone nowhere.com> writes:
On Saturday, 20 February 2021 at 16:55:30 UTC, 12345swordy wrote:
 On Saturday, 20 February 2021 at 16:48:43 UTC, bachmeier wrote:
 Doesn't it already do that? https://dlang.org/windbg.html

 (Maybe I'm not understanding.)
Read this line here: "The debug information format used is an ancient version of CodeView that is only partially supported by more recent debuggers."
`dmd -m64 -g foo.d` generates `foo.{exe,pdb}` and can be debugged with VS / Visual D just fine, no Dwarf involved.
Feb 20
next sibling parent kinke <noone nowhere.com> writes:
And with -m32mscoff too for 32-bit. The quoted sentence only 
applies to the 32-bit OMF backend.
Feb 20
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 20 February 2021 at 17:07:07 UTC, kinke wrote:
 On Saturday, 20 February 2021 at 16:55:30 UTC, 12345swordy 
 wrote:
 On Saturday, 20 February 2021 at 16:48:43 UTC, bachmeier wrote:
 Doesn't it already do that? https://dlang.org/windbg.html

 (Maybe I'm not understanding.)
Read this line here: "The debug information format used is an ancient version of CodeView that is only partially supported by more recent debuggers."
`dmd -m64 -g foo.d` generates `foo.{exe,pdb}` and can be debugged with VS / Visual D just fine, no Dwarf involved.
What part of "Ancient version of CodeView that is only partially supported" that you do not understand here? It doesn't generate enum type information or any type information at all for the debugger. Try reading the enum values in your debugging windows in visual d. It makes you want to rip your hair out. -Alex
Feb 20
parent reply kinke <noone nowhere.com> writes:
On Saturday, 20 February 2021 at 19:18:37 UTC, 12345swordy wrote:
 Try reading the enum values in your debugging windows in visual 
 d. It makes you want to rip your hair out.
I don't know what you mean; the fully qualified value name works good enough for me. Can you be more specific or link to some DMD issue?
Feb 20
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 20 February 2021 at 23:17:15 UTC, kinke wrote:
 On Saturday, 20 February 2021 at 19:18:37 UTC, 12345swordy 
 wrote:
 Try reading the enum values in your debugging windows in 
 visual d. It makes you want to rip your hair out.
I don't know what you mean; the fully qualified value name works good enough for me. Can you be more specific or link to some DMD issue?
https://ibb.co/0q6NkZk Look at the bottom left window. It display enum values as integers! -Alex
Feb 20
parent reply kinke <noone nowhere.com> writes:
On Saturday, 20 February 2021 at 23:33:05 UTC, 12345swordy wrote:
 https://ibb.co/0q6NkZk
 Look at the bottom left window.
 It display enum values as integers!

 -Alex
Not for trivial cases: https://ibb.co/YBK4H7q So this seems to be a bug, most likely not the last, but doesn't entail reinventing the wheel; .pdb output is already there.
Feb 20
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 20 February 2021 at 23:56:14 UTC, kinke wrote:
 On Saturday, 20 February 2021 at 23:33:05 UTC, 12345swordy 
 wrote:
 https://ibb.co/0q6NkZk
 Look at the bottom left window.
 It display enum values as integers!

 -Alex
Not for trivial cases: https://ibb.co/YBK4H7q
Have you ever tried to diagnose the pdb file? I did. It doesn't contain any information regarding any types. That's the issue here.
 So this seems to be a bug, most likely not the last, but 
 doesn't entail reinventing the wheel; .pdb output is already 
 there.
It does entail reinventing the wheel if you relying on an ancient version of CodeView! -Alex
Feb 20
parent reply kinke <noone nowhere.com> writes:
On Sunday, 21 February 2021 at 00:21:06 UTC, 12345swordy wrote:
 Have you ever tried to diagnose the pdb file? I did. It doesn't 
 contain any information regarding any types. That's the issue 
 here.
I actually have a while back while trying to improve LDC's CodeView output (for the object files, which is then bundled to a .pdb by the linker). For my little dummy example, I get this: llvm-pdbutil.exe dump --type-stats current.pdb Type Record Stats ============================================================ Types Total: 11697 entries ( 560,936 bytes, 47.96 avg) -------------------------------------------------------------------------- LF_FIELDLIST: 877 entries ( 197,188 bytes, 224.84 avg) LF_CLASS: 643 entries ( 95,280 bytes, 148.18 avg) LF_MFUNCTION: 2954 entries ( 82,712 bytes, 28.00 avg) LF_STRUCTURE: 783 entries ( 70,584 bytes, 90.15 avg) LF_ARGLIST: 1736 entries ( 30,104 bytes, 17.34 avg) LF_POINTER: 2110 entries ( 25,320 bytes, 12.00 avg) LF_PROCEDURE: 1179 entries ( 18,864 bytes, 16.00 avg) LF_ENUM: 184 entries ( 17,932 bytes, 97.46 avg) LF_METHODLIST: 410 entries ( 10,264 bytes, 25.03 avg) LF_MODIFIER: 430 entries ( 5,160 bytes, 12.00 avg) LF_ARRAY: 250 entries ( 4,000 bytes, 16.00 avg) LF_UNION: 41 entries ( 2,320 bytes, 56.59 avg) LF_BITFIELD: 88 entries ( 1,056 bytes, 12.00 avg) LF_VTSHAPE: 12 entries ( 152 bytes, 12.67 avg) And `llvm-pdbutil dump --types` does include my little E enum with its 3 values, the S struct with its 2 fields... 0x1000 | LF_FIELDLIST [size = 28] - LF_ENUMERATE [a = 0] - LF_ENUMERATE [b = 1] - LF_ENUMERATE [c = 2] 0x1001 | LF_ENUM [size = 28] `current.E` field list: 0x1000, underlying type: 0x0074 (int) options: ... 0x1006 | LF_FIELDLIST [size = 32] - LF_MEMBER [name = `e`, Type = 0x1004, offset = 0, attrs = public] - LF_MEMBER [name = `arr`, Type = 0x1005, offset = 4, attrs = public] 0x1007 | LF_STRUCTURE [size = 32] `current.S` vtable: <no type>, base list: <no type>, field list: 0x1006 options: , sizeof 12 ...
Feb 20
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 21 February 2021 at 00:42:46 UTC, kinke wrote:
 On Sunday, 21 February 2021 at 00:21:06 UTC, 12345swordy wrote:
 Have you ever tried to diagnose the pdb file? I did. It 
 doesn't contain any information regarding any types. That's 
 the issue here.
I actually have a while back while trying to improve LDC's CodeView output (for the object files, which is then bundled to a .pdb by the linker). For my little dummy example, I get this: llvm-pdbutil.exe dump --type-stats current.pdb Type Record Stats ============================================================ Types Total: 11697 entries ( 560,936 bytes, 47.96 avg) -------------------------------------------------------------------------- LF_FIELDLIST: 877 entries ( 197,188 bytes, 224.84 avg) LF_CLASS: 643 entries ( 95,280 bytes, 148.18 avg) LF_MFUNCTION: 2954 entries ( 82,712 bytes, 28.00 avg) LF_STRUCTURE: 783 entries ( 70,584 bytes, 90.15 avg) LF_ARGLIST: 1736 entries ( 30,104 bytes, 17.34 avg) LF_POINTER: 2110 entries ( 25,320 bytes, 12.00 avg) LF_PROCEDURE: 1179 entries ( 18,864 bytes, 16.00 avg) LF_ENUM: 184 entries ( 17,932 bytes, 97.46 avg) LF_METHODLIST: 410 entries ( 10,264 bytes, 25.03 avg) LF_MODIFIER: 430 entries ( 5,160 bytes, 12.00 avg) LF_ARRAY: 250 entries ( 4,000 bytes, 16.00 avg) LF_UNION: 41 entries ( 2,320 bytes, 56.59 avg) LF_BITFIELD: 88 entries ( 1,056 bytes, 12.00 avg) LF_VTSHAPE: 12 entries ( 152 bytes, 12.67 avg) And `llvm-pdbutil dump --types` does include my little E enum with its 3 values, the S struct with its 2 fields... 0x1000 | LF_FIELDLIST [size = 28] - LF_ENUMERATE [a = 0] - LF_ENUMERATE [b = 1] - LF_ENUMERATE [c = 2] 0x1001 | LF_ENUM [size = 28] `current.E` field list: 0x1000, underlying type: 0x0074 (int) options: ... 0x1006 | LF_FIELDLIST [size = 32] - LF_MEMBER [name = `e`, Type = 0x1004, offset = 0, attrs = public] - LF_MEMBER [name = `arr`, Type = 0x1005, offset = 4, attrs = public] 0x1007 | LF_STRUCTURE [size = 32] `current.S` vtable: <no type>, base list: <no type>, field list: 0x1006 options: , sizeof 12 ...
We are talking about the pdb files being when compiling dmd with dmd and not by ldc here. That the issue here. Run the llvm-pdbutil for the pdb file generated when comping dmd and you will see the problem. -Alex
Feb 20
parent reply kinke <noone nowhere.com> writes:
On Sunday, 21 February 2021 at 01:14:57 UTC, 12345swordy wrote:
 We are talking about the pdb files being when compiling dmd 
 with dmd and not by ldc here. That the issue here. Run the 
 llvm-pdbutil for the pdb file generated when comping dmd and 
 you will see the problem.
This *is* the DMD output dude...
Feb 21
parent reply kinke <noone nowhere.com> writes:
On Sunday, 21 February 2021 at 09:57:42 UTC, kinke wrote:
 On Sunday, 21 February 2021 at 01:14:57 UTC, 12345swordy wrote:
 We are talking about the pdb files being when compiling dmd 
 with dmd and not by ldc here. That the issue here. Run the 
 llvm-pdbutil for the pdb file generated when comping dmd and 
 you will see the problem.
This *is* the DMD output dude...
Sorry, missed the '*compiling dmd* with dmd' part. Well, *you* are *now* talking about that specific non-trivial project with a lot of extern(C++). You started out with .pdb generation, mentioning some DWARF-to-PDB conversion, ripping some 'ancient CodeView' quote out of its -m32 context, then went on with claiming that DMD wouldn't output any type debuginfos at all etc., so you seemed to go in a completely wrong direction. Most stuff is working as expected; what isn't ought to be analyzed and fixed as with any other bugs and limitations.
Feb 21
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 21 February 2021 at 11:39:29 UTC, kinke wrote:
 On Sunday, 21 February 2021 at 09:57:42 UTC, kinke wrote:
 On Sunday, 21 February 2021 at 01:14:57 UTC, 12345swordy wrote:
 [...]
This *is* the DMD output dude...
Sorry, missed the '*compiling dmd* with dmd' part. Well, *you* are *now* talking about that specific non-trivial project with a lot of extern(C++). You started out with .pdb generation, mentioning some DWARF-to-PDB conversion, ripping some 'ancient CodeView' quote out of its -m32 context, then went on with claiming that DMD wouldn't output any type debuginfos at all etc., so you seemed to go in a completely wrong direction. Most stuff is working as expected; what isn't ought to be analyzed and fixed as with any other bugs and limitations.
The solution file that comes with dmd isn't generating any type information for dmd apparently. -Alex
Feb 21
prev sibling parent Rumbu <rumbu rumbu.ro> writes:
On Saturday, 20 February 2021 at 23:56:14 UTC, kinke wrote:
 On Saturday, 20 February 2021 at 23:33:05 UTC, 12345swordy 
 wrote:
 https://ibb.co/0q6NkZk
 Look at the bottom left window.
 It display enum values as integers!

 -Alex
Not for trivial cases: https://ibb.co/YBK4H7q So this seems to be a bug, most likely not the last, but doesn't entail reinventing the wheel; .pdb output is already there.
DMD will not output enum info if the underlying enum type is not int. https://github.com/dlang/dmd/blob/32313b9f696520fae4910b96d5e4e6bd9b28e4a8/src/dmd/tocvdebug.d#L154 And to clear some misconceptions here, PDB uses CodeView format internally.
Feb 21