Silver (and probably other languages) generates broken PDBs and binaries

Elements Elements Bugs
, , , ,
1

IDE: Visual Studio 2015
Version: Elements 9.1
Target: Island(Windows 10 32-bit)
Description:

I am unable to debug binaries creates using Silver in WinDbg, profile them with xperf, get useful information about them using ProcMon, or do anything that requires actually working PDBs.

Expected Behavior: Getting a working PDB and a valid debug directory in the EXE.

Actual Behavior: PDB is useless. Binary doesn’t have a normal debug directory.

WinDbg:

0:003> lm m Basic*
Browse full module list
start    end        module name
00bd0000 00ce4600   BasicWindowsApp T (no symbols)

0:003> !lmi BasicWindowsApp
Loaded Module Info: [basicwindowsapp] 
         Module: BasicWindowsApp
   Base Address: 00bd0000
     Image Name: BasicWindowsApp
   Machine Type: 332 (I386)
     Time Stamp: 0 Wed Dec 31 16:00:00 1969
           Size: 114600
       CheckSum: 0
Characteristics: 102  
Debug Data Dirs: Type  Size     VA  Pointer
             CODEVIEW    40, 5f184,       0  [Debug data not mapped] - Can't validate symbols, if present.
     Image Type: FILE     - Image read successfully from debugger.
                 C:\Users\Public\Documents\RemObjects Samples\RemObjects Silver for Island\GUI\Basic Windows GUI App\bin\Debug\Windows\i386\BasicWindowsApp.exe
    Symbol Type: NONE     - No error - symbol load deferred from image path.
    Load Report: no symbols loaded

0:003> .symopt
Symbol options are 0x80030BF7:
  0x00000001 - SYMOPT_CASE_INSENSITIVE
  0x00000002 - SYMOPT_UNDNAME
  0x00000004 - SYMOPT_DEFERRED_LOADS
  0x00000010 - SYMOPT_LOAD_LINES
  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
  0x00000040 - SYMOPT_LOAD_ANYTHING
  0x00000080 - SYMOPT_IGNORE_CVREC
  0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
  0x00000800 - SYMOPT_ALLOW_ABSOLUTE_SYMBOLS
  0x00010000 - SYMOPT_AUTO_PUBLICS
  0x00020000 - SYMOPT_NO_IMAGE_SEARCH
  0x80000000 - SYMOPT_DEBUG

0:003> .reload /f /i BasicWindowsApp
DBGHELP: unrecognized OMF sig: 5a4d MZ*** WARNING: Unable to verify timestamp for BasicWindowsApp
*** ERROR: Module load completed but symbols could not be loaded for BasicWindowsApp
DBGHELP: BasicWindowsApp - no symbols loaded


0:003> lm m ntdll
Browse full module list
start    end        module name
77ce0000 77e6d000   ntdll      (pdb symbols)          c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb

0:003> !lmi ntdll
Loaded Module Info: [ntdll] 
         Module: ntdll
   Base Address: 77ce0000
     Image Name: C:\WINDOWS\SYSTEM32\ntdll.dll
   Machine Type: 332 (I386)
     Time Stamp: fce2c2c7
           Size: 18d000
       CheckSum: 1902fc
Characteristics: 2102  
Debug Data Dirs: Type  Size     VA  Pointer
             CODEVIEW    22, 1f98c,   1ed8c RSDS - GUID: {76326490-2E83-93C9-68B6-CA19849C168C}
               Age: 1, Pdb: ntdll.pdb
                   ??   62c, 1f9b0,   1edb0 [Data not mapped]
                   ??     0,     0,       0  [Debug data not mapped]
     Image Type: FILE     - Image read successfully from debugger.
                 C:\WINDOWS\SYSTEM32\ntdll.dll
    Symbol Type: PDB      - Symbols loaded successfully from image path.
                 c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb
    Load Report: public symbols , not source indexed 
                 c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb

DBH:

dbh: load c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb


ntdll [1000000]: info

    SizeOfStruct : 0x690
     BaseOfImage : 0x1000000
       ImageSize : 0x1000000
   TimeDateStamp : 0x0
        CheckSum : 0x0
         NumSyms : 0x0
         SymType : SymPdb
      ModuleName : ntdll
       ImageName : c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb
 LoadedImageName : c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb
   LoadedPdbName : c:\symbols\microsoft\ntdll.pdb\763264902E8393C968B6CA19849C168C1\ntdll.pdb
           CVSig : 0x0
          CVData :
          PdbSig : 0x0
        PdbSig70 : 0x76326490, 0x2e83, 0x93c9, 0x68, 0xb6, 0xca, 0x19, 0x84, 0x9c, 0x16, 0x8c
          PdbAge : 0x1
    PdbUnmatched : true
    DbgUnmatched : false
     LineNumbers : false
   GlobalSymbols : false
        TypeInfo : true
   SourceIndexed : false
   PublicSymbols : true
     MachineType : unknown

ntdll [1000000]: x NtCreateP*

 index            address     name
     1            1093000 :   NtCreateProcessEx
     2            1093020 :   NtCreateProcess
     3            1093060 :   NtCreatePort
     4            1093040 :   NtCreatePrivateNamespace
     5            1093080 :   NtCreatePagingFile
     6            1092fe0 :   NtCreateProfile
     7            1092d80 :   NtCreatePartition
     8            1092fc0 :   NtCreateProfileEx


dbh: load C:\Users\Public\Documents\RemObjects Samples\RemObjects Silver for Island\GUI\Basic Windows GUI App\bin\Debug\Windows\i386\BasicWindowsApp.pdb


BasicWindowsApp [1000000]: info

    SizeOfStruct : 0x690
     BaseOfImage : 0x1000000
       ImageSize : 0x1000000
   TimeDateStamp : 0x0
        CheckSum : 0x0
         NumSyms : 0x0
         SymType : SymPdb
      ModuleName : BasicWindowsApp
       ImageName : C:\Users\Public\Documents\RemObjects Samples\RemObjects Silver for Island\GUI\Basic Windows GUI App\bin\Debug\Windows\i386\BasicWindowsApp.pdb
 LoadedImageName : C:\Users\Public\Documents\RemObjects Samples\RemObjects Silver for Island\GUI\Basic Windows GUI App\bin\Debug\Windows\i386\BasicWindowsApp.pdb
   LoadedPdbName : C:\Users\Public\Documents\RemObjects Samples\RemObjects Silver for Island\GUI\Basic Windows GUI App\bin\Debug\Windows\i386\BasicWindowsApp.pdb
           CVSig : 0x0
          CVData :
          PdbSig : 0x0
        PdbSig70 : 0xa596016c, 0x6956, 0xaa4f, 0xc1, 0x7f, 0x38, 0x7d, 0x91, 0xb6, 0x1e, 0xe4
          PdbAge : 0x1
    PdbUnmatched : true
    DbgUnmatched : false
     LineNumbers : false
   GlobalSymbols : false
        TypeInfo : false
   SourceIndexed : false
   PublicSymbols : false
     MachineType : unknown

BasicWindowsApp [1000000]: x *


BasicWindowsApp [1000000]:

And so on.

Steps:

  1. Install Elements 9.1
  2. Open.
  3. Pick Silver.
  4. Pick Platform: Island, Category: GUI.
  5. Open Basic Windows GUI App.
  6. Go to project properties.
  7. Set Generate Debyg Symbols to True in all columns (except for Default).
  8. Build.
  9. Try to do anything with the PDB…
2

Thanks, logged as bugs://78404

3

We currently use Dwarf debug info, which is mutually exclusive with CodeView, it shouldn’t emit a pdb at all at the moment. That said, it might be possible to emit codeview debug info (which our dbugger does not support) or dwarf with a switch.

4

Well, that’s a separate problem.

In the initial versions (when Island was still called “beta”) you indeed did no emit a PDB. I thought the change is intentional.

Using DWARF - or anything else but CV for that matter - is unsatisfactory.
There is a difference between generating native code and giving a native experience on the native platform.
It’s very nice that you generate native code, in the sense that it is executed directly by the CPU rather than by something like the JVM or the CLR, but that’s far from providing the native experience.

Windows is a platform. The Windows platform is a lot more than “something that executes IA-32 code” (and even that’s not true with MIPS, SuperH and ARM support). It’s a platform. It’s an entire ecosystem.

When working on the Windows platform I expect to be able to look at stack traces in Sysinternals’ Process Monitor and in xperf/WPR traces. I expect to be able to debug the process in WinDbg and analyze dump files in it. All of this requires PDBs (and preferably appropriate debug directories in the executables).

Supplying only DWARF debug info for Windows binaries is analogous to supplying only CV debug info for Linux or macOS binaries. Utterly pointless.

Your publicity (propaganda?) says:

Let this sink in: You can now use C# to write CPU-native Windows code.

(Island | RemObjects Software)

But that’s hardly interesting. ngen and .NET native can do more or less the same. And they do provide PDBs…

PDBs are one of the most basic requirements of a native Windows toolchain. LLVM got that.
It is a necessary, yet not sufficient, condition for your tools to be even considered as a native development environment.

Without PDBs, it’s all useless for me, and I’m left with Visual C++ and Delphi, more or less.

5

I already said I wanted to support it. LLVM has only got pdb support very recently, and it was buggy when I tried it 6 months ago. The plan is to have a switch to select which debug info format to use.

Now that the documentation for pdb files is out, it might even be possible to expand our debugger to support PDB in the future.

6

Thanks, logged as bugs://78412

7

Were there swastikas along with it? if not, it probably was not propaganda.

8

I may have missed that. I see you said it might be possible. My reply tried to explain why it’s important.

Even with the so-called documentation Microsoft released there’s some non-trivial work to do, but it should be a somewhat easier.

Notice that long before Microsoft opened the microsoft-pdb repo the guys at Digital Mars made a utility to convert DWARF (or the subset they used) to PDB and later added support to generate PDBs directly (I think).

They may not support all the new clever features (inline functions information - formerly d2zi - for example), but it’s still something.

If and when you put this feature into your roadmap, I’d be happy to hear about it.
I’m pretty excited about and interested in the native support in your toolchain, but as I said, at least for my needs, it’s not quite there yet.

Thanks.

9

bugs://78412 got closed with status fixed.

10

Hi,

So this works now. The compiler emits both DWARF and PDB debug info. So you get a pdb next to the exe/dll and it has dwarf debug info too. Both debuggers work.

11

Hi Carlo.

Thanks for the update. This is very interesting to hear.
Unfortunately I see that this is available only on v10 which is only available to active subscribers right now so I can’t really experiment with this.

Is a stable build of v10 expected soon?

12

Next month, I would expect.

1 Like