February 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to 12345swordy | 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 ... | |||
Permalink
ReplyFebruary 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to kinke | 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
| |||
February 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to kinke | 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. | |||
February 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | 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...
| |||
February 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
Posted in reply to kinke | 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.
| |||
February 21, 2021 Re: The dmd backend should generate .pdb files for visual studio. | ||||
|---|---|---|---|---|
| ||||
Posted in reply to kinke | 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
| |||
Copyright © 1999-2021 by the D Language Foundation