Add a few basic tests for llvm-pdbdump

[zturner]

Summary

This is my first time writing a lit test, so I'm not sure if I really did this right.

[dblaikie]

Might be helpful to show the full (or at least abbreviated) output & explain what you're trying to test for/against - since I haven't actually seen the output of pdbdump, it's hard to tell what the tests would catch/avoid/etc.

test/DebugInfo/PDB/Inputs/symbolformat-fpo.cpp

6 ↗

(On Diff #19992)

add the missing newline here

test/DebugInfo/PDB/Inputs/symbolformat.cpp

1 ↗

(On Diff #19992)

do you need stdio here? It'd be best to have standalone examples as much as possible.

[zturner]

Fixed suggested issues. To address the issue of displaying the output format so you can see what it looks like, I opted to instead just include the full output as part of the test. If someone recompiles the files, they will need to change these. I could have used a regex as before to make the lines independent of address, but I felt like it detracted from the readability of the test.

[zturner]

The last diff didn't generate correctly for some reason. Try this one.

[zturner]

Bump. The options being specified on the command line might be a little confusing. I actually have a followup patch which drastically simplifies the options and probably will make reading these tests easier. But I was goign to commit that after this (as the patch updates the tests and output as well).

In any case, the basic idea of pdbdump-symbol-format.test is to dump symbol entries from object files. Since we don't know what the internal format of PDB is, I wrote the dumper to dump entries in ways that would make it easier for people to understand what the information in the PDB represents *semantically*, as opposed to physically. This is useful for someone writing a debugger, for example, so that they can know at a high level what kind of information they can expect to get from the PDB.

In this example, you can see that the PDB knows about 2 object files, symbolformat.obj and symbolformat-fpo.obj. For each one, all the symbols are dumped, which consist mostly of functions due to the fact that the original source code also consists mostly of functions. RVAs of the functions are dumped as well, in a format like [start+prologue_length - end-epilogue_length]

[zturner]

RVA - relative virtual address (i.e. offset from the beginning of the
module, so that when it is loaded at runtime, you add that value to the
module load address to get the absolute virtual address of the symbol). I
thought this was a universal term, but I guess not :) What does DWARF call
this?

[zturner]

I had to revert this because of some failing bots.

Examples:
http://lab.llvm.org:8011/builders/llvm-s390x-linux1/builds/13731/steps/test-llvm/logs/stdio
http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/15858/steps/test-llvm/logs/stdio

Although there were a few others. Now obviously the test should register as unsupported on those platforms, but they're not. I tested this on both my Linux and my Mac workstations and the tests correctly didn't run due to being unsupported. But I'm not sure how to diagnose the problem further of why they are not getting flagged as unsupported here.

HAVE_DIA_SDK is only set to 1 under an "if (MSVC)" check in the CMake, so I've no idea why it might be getting set here, or if something else might be going on. David, Chandler, any ideas how to figure this out?

llvm/trunk/test/DebugInfo/PDB/Inputs/empty.cpp

+// Build with "cl.exe /Zi empty.cpp /link /debug /nodefaultlib /entry:main"
+
+void *__purecall = 0;
+
+int main() {
+  return 42;
+}

llvm/trunk/test/DebugInfo/PDB/Inputs/symbolformat-fpo.cpp

+// Compile with "cl /GR- /Zi /c /Ox /Oy symbolformat-fpo.cpp"
+// Refer to symbolformat.cpp for linking instructions.
+
+unsigned fpo_func(unsigned n) {
+  return n * 2;
+}

llvm/trunk/test/DebugInfo/PDB/Inputs/symbolformat.cpp

+// Compile with "cl /c /Zi /GR- symbolformat.cpp"
+// Compile symbolformat-fpo.cpp (see file for instructions)
+// Link with "link symbolformat.obj symbolformat-fpo.obj /debug /nodefaultlib
+//    /entry:main /out:symbolformat.exe"
+
+int __cdecl _purecall(void) { return 0; }
+
+struct A {
+  virtual void PureFunc() = 0 {}
+  virtual void VirtualFunc() {}
+  void RegularFunc() {}
+};
+
+struct B : public A {
+  void PureFunc() override {}
+};
+
+int main(int argc, char **argv) {
+  B b;
+  auto PureAddr = &B::PureFunc;
+  auto VirtualAddr = &A::PureFunc;
+  auto RegularAddr = &A::RegularFunc;
+  return 0;
+}

llvm/trunk/test/DebugInfo/PDB/lit.local.cfg

+config.unsupported = not config.have_dia_sdk

llvm/trunk/test/DebugInfo/PDB/pdbdump-flags.test

+; RUN: llvm-pdbdump %p/Inputs/empty.pdb | FileCheck %s -check-prefix SUMMARY_CHECK
+; RUN: llvm-pdbdump -functions %p/Inputs/empty.pdb | FileCheck %s -check-prefix MAIN_CHECK
+
+; Check PDB file summary information
+; SUMMARY_CHECK: empty.pdb
+; SUMMARY_CHECK: Guid: {0B355641-86A0-A249-896F-9988FAE52FF0}
+; SUMMARY_CHECK: Attributes: HasPrivateSymbols
+
+; Check that running with only -compilands doesn't include unwanted symbol types
+; MAIN_CHECK: (EBP) int32_t __cdecl main()
+; MAIN_CHECK-NOT: vtbl:
+; MAIN_CHECK-NOT: enum:
+; MAIN_CHECK-NOT: class:
+; MAIN_CHECK-NOT: data:

llvm/trunk/test/DebugInfo/PDB/pdbdump-symbol-format.test

+; RUN: llvm-pdbdump -all -hidden -group-by=compiland %p/Inputs/symbolformat.pdb | FileCheck --check-prefix=FORMAT %s
+
+; The format here is func [0x<rva_start>+<prologue_length> - 0x<rva_end>-<epilogue_length>]
+; FORMAT: test\DebugInfo\PDB\Inputs\symbolformat-fpo.obj
+; FORMAT-DAG: func [0x001130+0 - 0x001137-1] (VFrame) uint32_t __cdecl fpo_func(uint32_t)
+; FORMAT: d:\src\llvm\test\DebugInfo\PDB\Inputs\symbolformat.obj
+; FORMAT-DAG: func [0x001060+3 - 0x001067-2] (EBP) int32_t __cdecl _purecall()
+; FORMAT-DAG: func [0x001070+6 - 0x001099-4] (EBP) int32_t __cdecl main(int32_t, char**)
+; FORMAT-DAG: func [0x0010b0+7 - 0x0010c7-4] (EBP) void __thiscall A::A()
+; FORMAT-DAG: func [0x0010d0+7 - 0x0010ef-4] (EBP) void __thiscall B::B()
+; FORMAT-DAG: thunk [0x000010f6 - 0x000010fa] (Pcode) B::`vcall'{0}'
+; FORMAT-DAG: func [0x001100+7 - 0x00110b-4] (EBP) virtual void __thiscall B::PureFunc()
+; FORMAT-DAG: func [0x001110+7 - 0x00111b-4] (EBP) void __thiscall A::RegularFunc()
+; FORMAT-DAG: func [0x001120+7 - 0x00112b-4] (EBP) virtual void __thiscall A::VirtualFunc()

llvm/trunk/test/lit.site.cfg.in

 config.host_os = "@HOST_OS@"
 config.host_arch = "@HOST_ARCH@"
 config.host_cc = "@HOST_CC@"
 config.host_cxx = "@HOST_CXX@"
 config.host_ldflags = "@HOST_LDFLAGS@"
 config.llvm_use_intel_jitevents = "@LLVM_USE_INTEL_JITEVENTS@"
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = "@HAVE_LIBZ@"
+config.have_dia_sdk = "@HAVE_DIA_SDK@"
 config.enable_ffi = "@LLVM_ENABLE_FFI@"
 
 # Support substitution of the tools_dir with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
 try:
     config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
     config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
     e = sys.exc_info()[1]
     key, = e.args
     lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@LLVM_SOURCE_DIR@/test/lit.cfg")