digitalmars.D - The dmd backend should generate .pdb files for visual studio.
- 12345swordy (10/10) Feb 20 2021 I think it time for dmd to do so, as the backend is currently
- bachmeier (3/13) Feb 20 2021 Doesn't it already do that? https://dlang.org/windbg.html
- 12345swordy (6/8) Feb 20 2021 Read this line here:
- kinke (3/12) Feb 20 2021 `dmd -m64 -g foo.d` generates `foo.{exe,pdb}` and can be debugged
- kinke (2/2) Feb 20 2021 And with -m32mscoff too for 32-bit. The quoted sentence only
- 12345swordy (8/22) Feb 20 2021 What part of "Ancient version of CodeView that is only partially
- kinke (4/6) Feb 20 2021 I don't know what you mean; the fully qualified value name works
- 12345swordy (5/12) Feb 20 2021 https://ibb.co/0q6NkZk
- kinke (4/8) Feb 20 2021 Not for trivial cases: https://ibb.co/YBK4H7q
- 12345swordy (7/18) Feb 20 2021 Have you ever tried to diagnose the pdb file? I did. It doesn't
- kinke (61/64) Feb 20 2021 I actually have a while back while trying to improve LDC's
- 12345swordy (6/70) Feb 20 2021 We are talking about the pdb files being when compiling dmd with
- kinke (2/6) Feb 21 2021 This *is* the DMD output dude...
- kinke (10/16) Feb 21 2021 Sorry, missed the '*compiling dmd* with dmd' part. Well, *you*
- 12345swordy (4/18) Feb 21 2021 The solution file that comes with dmd isn't generating any type
- Rumbu (6/17) Feb 21 2021 DMD will not output enum info if the underlying enum type is not
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 2021
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? -AlexDoesn't it already do that? https://dlang.org/windbg.html (Maybe I'm not understanding.)
Feb 20 2021
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 2021
On Saturday, 20 February 2021 at 16:55:30 UTC, 12345swordy wrote:On Saturday, 20 February 2021 at 16:48:43 UTC, bachmeier wrote:`dmd -m64 -g foo.d` generates `foo.{exe,pdb}` and can be debugged with VS / Visual D just fine, no Dwarf involved.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."
Feb 20 2021
kinke <noone nowhere.com> And with -m32mscoff too for 32-bit. The quoted sentence only applies to the 32-bit OMF backend.
Feb 20 2021
On Saturday, 20 February 2021 at 17:07:07 UTC, kinke wrote:On Saturday, 20 February 2021 at 16:55:30 UTC, 12345swordy wrote: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. -AlexOn Saturday, 20 February 2021 at 16:48:43 UTC, bachmeier wrote:`dmd -m64 -g foo.d` generates `foo.{exe,pdb}` and can be debugged with VS / Visual D just fine, no Dwarf involved.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."
Feb 20 2021
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 2021
On Saturday, 20 February 2021 at 23:17:15 UTC, kinke wrote:On Saturday, 20 February 2021 at 19:18:37 UTC, 12345swordy wrote:https://ibb.co/0q6NkZk Look at the bottom left window. It display enum values as integers! -AlexTry 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 2021
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! -AlexNot 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 2021
On Saturday, 20 February 2021 at 23:56:14 UTC, kinke wrote:On Saturday, 20 February 2021 at 23:33:05 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.https://ibb.co/0q6NkZk Look at the bottom left window. It display enum values as integers! -AlexNot for trivial cases: https://ibb.co/YBK4H7qSo 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 2021
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 2021
On Sunday, 21 February 2021 at 00:42:46 UTC, kinke wrote:On Sunday, 21 February 2021 at 00:21:06 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. -AlexHave 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 2021
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 2021
On Sunday, 21 February 2021 at 09:57:42 UTC, kinke wrote:On Sunday, 21 February 2021 at 01:14:57 UTC, 12345swordy wrote: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.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 2021
On Sunday, 21 February 2021 at 11:39:29 UTC, kinke wrote:On Sunday, 21 February 2021 at 09:57:42 UTC, kinke wrote:The solution file that comes with dmd isn't generating any type information for dmd apparently. -AlexOn Sunday, 21 February 2021 at 01:14:57 UTC, 12345swordy wrote: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.[...]This *is* the DMD output dude...
Feb 21 2021
On Saturday, 20 February 2021 at 23:56:14 UTC, kinke wrote:On Saturday, 20 February 2021 at 23:33:05 UTC, 12345swordy wrote: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.https://ibb.co/0q6NkZk Look at the bottom left window. It display enum values as integers! -AlexNot 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 21 2021