February 21
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
...
February 21
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
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
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
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
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
Next ›   Last »
1 2