Commit Graph

8 Commits

Author SHA1 Message Date
Adrian McCarthy 4aedc81b8c Fix build break by using llvm::make_unique instead of std::make_unique.
llvm-svn: 306043
2017-06-22 18:57:51 +00:00
Adrian McCarthy 31bcb6f680 Add IDs and clone methods to NativeRawSymbol
All NativeRawSymbols will have a unique symbol ID (retrievable via
getSymIndexId).  For now, these are initialized to 0, but soon the
NativeSession will be responsible for creating the raw symbols, and it will
assign unique IDs.

The symbol cache in the NativeSession will also require the ability to clone
raw symbols, so I've provided implementations for that as well.

llvm-svn: 306042
2017-06-22 18:43:18 +00:00
Zachary Turner 1eb9a0297c [PDB] Don't build the entire source file list up front.
I tried to run llvm-pdbdump on a very large (~1.5GB) PDB to
try and identify show-stopping performance problems.  This
patch addresses the first such problem.

When loading the DBI stream, before anyone has even tried to
access a single record, we build an in memory map of every
source file for every module.  In the particular PDB I was
using, this was over 85 million files.  Specifically, the
complexity is O(m*n) where m is the number of modules and
n is the average number of source files (including headers)
per module.

The whole reason for doing this was so that we could have
constant time access to any module and any of its source
file lists.  However, we can still get O(1) access to the
source file list for a given module with a simple O(m)
precomputation, and access to the list of modules is
already O(1) anyway.

So this patches reduces the O(m*n) up-front precomputation
to an O(m) one, where n is ~6,500 and n*m is about 85 million
in my pathological test case.

Differential Revision: https://reviews.llvm.org/D32870

llvm-svn: 302205
2017-05-04 23:53:29 +00:00
Adrian McCarthy 4d93d66ddd Re-land: "Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"
This should work on all platforms now that r299006 has landed.  Tested locally
on Windows and Linux.

This moves exe symbol-specific method implementations out of NativeRawSymbol
into a concrete subclass. Also adds implementations for hasCTypes and
hasPrivateSymbols and a simple test to ensure the native reader can access the
summary information for the executable from the PDB.

Original Differential Revision: https://reviews.llvm.org/D31059

llvm-svn: 299019
2017-03-29 19:27:08 +00:00
Adrian McCarthy 3c0328e011 Somehow this still breaks because of ANSI color codes in test output on Linux.
Reverting until I can figure out the root cause.

Revert "Re-land:  Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"

This reverts commit f461a70cc376f0f91c8b4917be79479cc86330a5.

llvm-svn: 298626
2017-03-23 17:18:50 +00:00
Adrian McCarthy 997a15c3c3 Re-land: Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]
The new test should pass on all platforms now that llvm-pdbdump has the
`-color-output` option.

This moves exe symbol-specific method implementations out of NativeRawSymbol
into a concrete subclass. Also adds implementations for hasCTypes and
hasPrivateSymbols and a simple test to ensure the native reader can access
the summary information for the executable from the PDB.

Original Differential Revision: https://reviews.llvm.org/D31059

llvm-svn: 298623
2017-03-23 16:45:20 +00:00
Zachary Turner 2d9c082033 Revert "Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"
For some reason this is causing ANSI color codes to be printed
even when run through FileCheck.

llvm-svn: 298026
2017-03-17 00:46:42 +00:00
Adrian McCarthy 21b54cf632 Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]
This moves exe symbol-specific method implementations out of NativeRawSymbol
into a concrete subclass. Also adds implementations for hasCTypes and
hasPrivateSymbols and a simple test to ensure the native reader can access
the summary information for the executable from the PDB.

Differential Revision: https://reviews.llvm.org/D31059

llvm-svn: 298005
2017-03-16 22:28:39 +00:00