Don't use uniform initialization syntax.

llvm-svn: 347020

[NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.

Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol th

[NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.

Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this. For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol. This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?

A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.

With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives. This gives us much better flexibility in
what kinds of symbols the uids can identify.

llvm-svn: 347018

show more ...

[NativePDB] Add support for S_CONSTANT records.

clang-cl does not emit these, but MSVC does, so we need to be able to
handle them.

Because clang-cl does not generate them, it was a bit hard to writ

[NativePDB] Add support for S_CONSTANT records.

clang-cl does not emit these, but MSVC does, so we need to be able to
handle them.

Because clang-cl does not generate them, it was a bit hard to write a
test. So what I had to do was get an PDB file with some S_CONSTANT
records in using cl and link, dump it using llvm-pdbutil dump -globals
-sym-data to get the bytes of the records, generate the same object file
using clang-cl but with -S to emit an assembly file, and replace all the
S_LDATA32 records with the bytes of the S_CONSTANT records. This way, we
can compile the file using llvm-mc and link it with lld-link.

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

llvm-svn: 346787

show more ...

[NativePDB] Improved support for nested type reconstruction.

In a previous patch, we pre-processed the TPI stream in order to build
the reverse mapping from nested type -> parent type so that we cou

[NativePDB] Improved support for nested type reconstruction.

In a previous patch, we pre-processed the TPI stream in order to build
the reverse mapping from nested type -> parent type so that we could
accurately reconstruct a DeclContext hierarchy.

However, there were some issues. An LF_NESTTYPE record is really just a
typedef, so although it happens to be used to indicate the name of the
nested type and referring to the global record which defines the type,
it is also used for every other kind of nested typedef. When we rebuild
the DeclContext hierarchy, we want it to be as accurate as possible,
which means that if we have something like:

struct A {
struct B {};
using C = B;
};

We don't want to create two CXXRecordDecls in the AST each with the
exact same definition. We just want to create one for B and then
define C as an alias to B. Previously, however, it would not be able
to distinguish between the two cases and it would treat A::B and
A::C as being two classes each with separate definitions. We address
the first half of improving the pre-processing logic so that only
actual definitions are treated this way.

Later, in a followup patch, we can handle the case of nested
typedefs since we're already going to be enumerating the field list
anyway and this patch introduces the general framework for
distinguishing between the two cases.

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

llvm-svn: 346786

show more ...

[NativePDB] Fix completion of enum types.

This was originally submitted in a patch which fixed two unrelated
bugs at the same time. This portion of the fix was reverted because
it broke several oth

[NativePDB] Fix completion of enum types.

This was originally submitted in a patch which fixed two unrelated
bugs at the same time. This portion of the fix was reverted because
it broke several other things. However, the fix employed originally
was totally wrong, and attempted to change something in the ValueObject
printer when actually the bug was in the NativePDB plugin. We need
to mark forward enum decls as having external storage, otherwise
we won't be asked to complete them when the time comes. This patch
implements the proper fix, and updates tests accordingly.

llvm-svn: 346517

show more ...

[NativePDB] Higher fidelity reconstruction of AST from Debug Info.

In order to accurately put a type into the correct location in the AST
we construct from debug info, we need to be able to determin

[NativePDB] Higher fidelity reconstruction of AST from Debug Info.

In order to accurately put a type into the correct location in the AST
we construct from debug info, we need to be able to determine what
DeclContext (namespace, global, nested class, etc) that it goes into.
PDB doesn't contain this mapping. It does, however, contain the reverse
mapping. That is, for a given class type T, you can determine all
classes Q1, Q2, ..., Qn that are nested inside of T. We need to know,
for a given class type Q, what type T is it nested inside of.

This patch builds this map as a pre-processing step when we first
load the PDB by scanning every type. Initial tests show that while
this can be slow in debug builds of LLDB, it is quite fast in release
builds (less than 2 seconds for a ~1GB PDB, and it only needs to happen
once).

Furthermore, having this pre-processing step in place allows us to
repurpose it for building up other kinds of indexing to it down the
line. For the time being, this gives us very accurate reconstruction
of the DeclContext hierarchy.

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

llvm-svn: 346429

show more ...

Fix (and improve) the support for C99 variable length array types

Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:

0x00000051: DW_TAG_variable [4]

Fix (and improve) the support for C99 variable length array types

Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:

0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )

0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )

Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.

See the testcase for an example:

4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }

(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit

rdar://problem/21814005

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

llvm-svn: 346165

show more ...

Add a target modules dump ast command.

This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.

Differential Revi

Add a target modules dump ast command.

This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.

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

llvm-svn: 346149

show more ...

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential revision: https://reviews.llvm.org/D53915

llvm-svn: 345890

show more ...

[NativePDB] Get LLDB types from PDB function types.

This adds basic support for getting function signature types
into LLDB's type system, including into clang's AST. There are
a few edge cases whic

[NativePDB] Get LLDB types from PDB function types.

This adds basic support for getting function signature types
into LLDB's type system, including into clang's AST. There are
a few edge cases which are not correctly handled, mostly dealing
with nested classes, but this isn't specific to functions and
apply equally to variable types. Note that no attempt has been
made yet to deal with member function types, which will happen
in subsequent patches.

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

llvm-svn: 345848

show more ...

[NativePDB] Add support for dumping global variables of class type.

Previous patches added support for dumping global variables of
primitive types, so we now do the same for class types.

For the mo

[NativePDB] Add support for dumping global variables of class type.

Previous patches added support for dumping global variables of
primitive types, so we now do the same for class types.

For the most part, everything just worked, there was only one
minor bug needing fixed, which was that for variables of modified
types (e.g. const, volatile, etc) we can't resolve the forward
decl in CreateAndCacheType because the PdbSymUid must point to the
LF_MODIFIER which must point to the forward decl. So when it comes
time to call CompleteType, an assert was firing because we expected
to get a class, struct, union, or enum, but we were getting an
LF_MODIFIER instead.

The other issue is that one the newly added tests is for an array
member, which was not yet supported, so we add support for that
now in this patch.

There's probably room for other interesting layout test cases
here, but this at least should test the basics.

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

llvm-svn: 345629

show more ...

[NativePDB] Add the ability to dump dump global variables.

LLDB has the ability to display global variables, even without a running
process, via the target variable command. This is because global
v

[NativePDB] Add the ability to dump dump global variables.

LLDB has the ability to display global variables, even without a running
process, via the target variable command. This is because global
variables are linker initialized, so their values are embedded directly
into the executables. This gives us great power for testing native PDB
functionality in a cross-platform manner, because we don't actually need
a running process. We can just create a target using an EXE file, and
display global variables. And global variables can have arbitrarily
complex types, so in theory we can fully exercise the type system,
record layout, and data formatters for native PDB files and PE/COFF
executables on any host platform, as long as our type does not require a
dynamic initializer.

This patch adds basic support for finding variables by name, and adds an
exhaustive test for fundamental data types and pointers / references to
fundamental data types.

Subsequent patches will extend this to typedefs, classes, pointers to
functions, and other cases.

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

llvm-svn: 345373

show more ...

Don't type-erase the FunctionNameType or TypeClass enums.

This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to th

Don't type-erase the FunctionNameType or TypeClass enums.

This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.

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

llvm-svn: 345314

show more ...

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with. We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with. This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum. This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313

show more ...

Fix some comments pointed out by Leonard Mosescu.

These were originally pointed out in D53511 but I forgot
to incorporate them in my patch.

llvm-svn: 345091

Remove unused variable.

llvm-svn: 345086

[NativePDB] Add basic support for tag types to the native pdb plugin.

This adds support to LLDB for named types (class, struct, union, and
enum). This is true cross platform support, and hits the P

[NativePDB] Add basic support for tag types to the native pdb plugin.

This adds support to LLDB for named types (class, struct, union, and
enum). This is true cross platform support, and hits the PDB file
directly without a dependency on Windows. Tests are added which
compile a program with certain interesting types and then use
load the target in LLDB and use "type lookup -- <TypeName>" to
dump the layout of the type in LLDB without a running process.

Currently only fields are parsed -- we do not parse methods. Also
we don't deal with bitfields or virtual bases correctly. Those
will make good followups.

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

llvm-svn: 345047

show more ...

Some cleanups to the native pdb plugin [NFC].

This is mostly some cleanup done in the process of implementing
some basic support for types. I tried to split up the patch a
bit to get some of the NF

Some cleanups to the native pdb plugin [NFC].

This is mostly some cleanup done in the process of implementing
some basic support for types. I tried to split up the patch a
bit to get some of the NFC portion of the patch out into a separate
commit, and this is the result of that. It moves some code around,
deletes some spurious namespace qualifications, removes some
unnecessary header includes, forward declarations, etc.

llvm-svn: 344913

show more ...

Try to fix some failures on MacOSX with the NativePDB patch.

This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.

It also adds better error checking, so that we

Try to fix some failures on MacOSX with the NativePDB patch.

This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.

It also adds better error checking, so that we don't get assertions
on the failure path when a file fails to parse as a PDB.

llvm-svn: 344429

show more ...

Resubmit "Add SymbolFileNativePDB plugin."

This was originally reverted due to some test failures on
Linux. Those problems turned out to require several additional
patches to lld and clang in order

Resubmit "Add SymbolFileNativePDB plugin."

This was originally reverted due to some test failures on
Linux. Those problems turned out to require several additional
patches to lld and clang in order to fix, which have since been
submitted. This patch is resubmitted unchanged. All tests now
pass on both Linux and Windows.

llvm-svn: 344409

show more ...

Better support for POSIX paths in PDBs.

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to

Better support for POSIX paths in PDBs.

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).

There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.

Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.

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

llvm-svn: 344269

show more ...

[lldb] Surpress copy-elison warning.

llvm-svn: 344252

[SymbolFileNativePDB] Fix compilation errors with gcc.

llvm-svn: 344173

Create a SymbolFile plugin for cross-platform PDB access.

The existing SymbolFilePDB only works on Windows, as it is written
against a closed-source Microsoft SDK that ships with their debugging
too

Create a SymbolFile plugin for cross-platform PDB access.

The existing SymbolFilePDB only works on Windows, as it is written
against a closed-source Microsoft SDK that ships with their debugging
tools.

There are several reasons we want to bypass this and go straight to the
bits of the PDB, but just to list a few:

More room for optimization. We can't see inside the implementation of
the Microsoft SDK, so we don't always know if we're doing things in the
most efficient way possible. For example, setting a breakpoint on main
of a big program currently takes several seconds. With the
implementation here, the time is unnoticeable.
We want to be able to symbolize Windows minidumps even if not on
Windows. Someone should be able to debug Windows minidumps as if they
were on Windows, given that no running process is necessary.
This patch is a very crude first attempt at filling out some of the
basic pieces.

I've implemented FindFunctions, ParseCompileUnitLineTable, and
ResolveSymbolContext for a limited subset of possible parameter values,
which is just enough to get it to display something nice for the
breakpoint location.

I've added several tests exercising this functionality which are limited
enough to work on all platforms but still exercise this functionality.
I'll try to add as many tests of this nature as I can, but at some
point we'll need a live process.

For now, this plugin is enabled always on non-Windows, and by setting
the environment variable LLDB_USE_NATIVE_PDB_READER=1 on Windows.
Eventually, once it's at parity with the Windows implementation, we'll
delete the Windows DIA-based implementation.

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

llvm-svn: 344154

show more ...