cvdump does not recognize symbol type 0x1168. PDB generated by VS 2017 C++.

[mrolle45]

I compiled a file containing a call to an inline function, using VS 2017. Running cvdump.exe produces an error message about a symbol record type 1168 (which is hex). Apparently, the new VS 2017 toolset is producing this record, and your cvinfo.h does not include it in the SYM_ENUM_e type.
I looked at this record in the PDB, and it contains the number 2, and type IDs for the two inline functions called in a function.
cvinfo.h needs updating. This is especially important as this file is being cited in various other web resources as the 'official' documentation of the symbol records in a PDB.
I also ran cvinfo.h on the OBJ file, with the same result.

Here's my example:

__inline int inl(int x)
{
return x + 1;
}

extern "C"
int seh(void)
{
X xx;
int x = xx.foo ();
x = inl(x);
...

cvdump output is:

(000728) S_GPROC32: [0002:00001F40], Cb: 00000084, Type: 0x2249, seh
Parent: 00000000, End: 000008E4, Next: 00000000
Debug start: 0000000E, Debug end: 0000007E

(000754) S_FRAMEPROC:
Frame size = 0x00000060 bytes
Pad size = 0x00000040 bytes
Offset of pad in frame = 0x00000020
Size of callee save registers = 0x00000000
Address of exception handler = 0000:00000000
Function info: seh invalid_pgo_counts opt_for_speed Local=rbp Param=rbp (0x00128040)
Error: unknown symbol record type 1168!

[sh1ftchg]

This repo needs updating. Yes, it doesn't understand the symbol, but really, it doesn't understand any of the new symbols.

[zjturner]

Hi,

I maintain the CodeView and PDB implementation in LLVM. If you're interested in having support for this and other new records, you might try filing a bug on the LLVM Bug Tracker (or email to llvm-dev mailing list).

It's certainly possible cvdump may get updated someday, but at least for the time being you will get a quicker turnaround time on improvements if you ping me on the llvm-dev mailing list.

(Not going to respond further here since the point of this message is to re-direct you, but happy to respond to any questions on llvm-dev mailing list)

[skochinsky]

@mrolle45 did you figure it out? If it's been discussed on the mailing list, can you post a link to the thread?

[skochinsky]

For future reference, I found a discussion of the record 0x1167:

http://lists.llvm.org/pipermail/llvm-dev/2017-June/113885.html

There's no real conclusion but there was this tidbit:

So, this symbol record with kind 0x1167 is pretty interesting, and clearly
related to /debug:fastlink. Its format can be deduced as something like
this:

struct DebugFastLinkRecord {
  char Unknown[6];
  char Name[0]; // null terminated string
  char Padding[0]; // pad to 4 bytes
};

What those first 6 bytes are I can't tell you.

So for now the mystery remains...

[Zhentar]

0x1168 is a FUNCTIONLIST of inlinees in the same format as S_CALLERS and S_CALLEES. LLVM chose to call it S_INLINEES, and DbgHelp symbols/string search suggest that choice was accurate.

0x1167 on the other hand was called "S_FASTLINK" by LLVM, but DbgHelp strings suggest it should in fact be S_REF_MINIPDB2 (oddly, this would mean REFMINIPDB2 is two bytes smaller than REFMINIPDB...)

[PascalBeyer]

S_REF_MINIPDB2 seems to be a version of S_REF_MINIPDB which dropped the imod field. I.e

typedef struct REFMINIPDB2 {
    unsigned short  reclen;             // Record length
    unsigned short  rectyp;             // S_REF_MINIPDB2
    union {
        unsigned long  isectCoff;       // coff section
        CV_typ_t       typind;          // type index
    };
    unsigned short  fLocal   :  1;      // reference to local (vs. global) func or data
    unsigned short  fData    :  1;      // reference to data (vs. func)
    unsigned short  fUDT     :  1;      // reference to UDT
    unsigned short  fLabel   :  1;      // reference to label
    unsigned short  fConst   :  1;      // reference to const
    unsigned short  reserved : 11;      // reserved, must be zero
    unsigned char   name[1];            // zero terminated name string
} REFMINIPDB2;

The imod field is sort of useless, since these entries are contained in the module symbol stream of module imod.
Hence, whenever you encounter a S_REF_MINIPDB you should already know imod.
This also lines up with the new struture being 2 bytes smaller!