Cleanup LLVMDebugInfoCodeView headers

Major user-facing changes:

Many headers in llvm/DebugInfo/CodeView no longer include
llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h,
th

Cleanup LLVMDebugInfoCodeView headers

Major user-facing changes:

Many headers in llvm/DebugInfo/CodeView no longer include
llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h,
those headers may need to be included manually.

Several headers in llvm/DebugInfo/CodeView no longer include
llvm/DebugInfo/CodeView/EnumTables.h or llvm/DebugInfo/CodeView/CodeView.h,
those headers may need to be included manually.

Some statistics:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/DebugInfo/CodeView/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after: 2794466
before: 2832765

Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/

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

show more ...

[lldb] Rename StringRef _lower() method calls to _insensitive()

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

Postfix: move more code out of the PDB plugin

Summary:
Previously we moved the code which parses a single expression out of the PDB
plugin, because that was useful for DWARF expressions in breakpad.

Postfix: move more code out of the PDB plugin

Summary:
Previously we moved the code which parses a single expression out of the PDB
plugin, because that was useful for DWARF expressions in breakpad. However, FPO
programs are used in breakpad files too (when unwinding on windows), so this
completes the job, and moves the rest of the FPO parser too.

Reviewers: amccarth, aleksandr.urakov

Subscribers: aprantl, markmentovai, rnk, lldb-commits

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

llvm-svn: 369894

show more ...

[COFF, ARM64] Fix CodeView API change for getRegisterNames

Change rL362280 changed CodeView API getRegisterNames() by adding an input
parameter in CPUType. It is called in LLDB and needs to be updat

[COFF, ARM64] Fix CodeView API change for getRegisterNames

Change rL362280 changed CodeView API getRegisterNames() by adding an input
parameter in CPUType. It is called in LLDB and needs to be updated.

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

llvm-svn: 362349

show more ...

Fix file names in file headers. NFC

llvm-svn: 360554

PostfixExpression: move DWARF generator out of NativePDB internals

Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.

In order to write a pdb-independent test for it

PostfixExpression: move DWARF generator out of NativePDB internals

Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.

In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.

I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.

Reviewers: amccarth, clayborg, aleksandr.urakov

Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere

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

llvm-svn: 359288

show more ...

PostfixExpression: move parser out of NativePDB internals

Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch

PostfixExpression: move parser out of NativePDB internals

Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch
generalizes the parser in the NativePDB plugin and moves it into the
PostfixExpression file created in the previous commit (r358976).

The generalization consists of treating any unrecognised token as a
"symbol" node (previously these would only be created for tokens
starting with "$", and other token would abort the parse). This is
needed because breakpad symbols can also contain ".cfa" tokens, which
refer to the frame's CFA.

The cosmetic changes include:
- using a factory function instead of a class for creating nodes (this
is more generic as it allows the same BumpPtrAllocator to be used for
other things too)
- using dedicated function for parsing operator tokens instead of a
DenseMap (more efficient as we don't need to create the DenseMap every
time).

Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov

Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny

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

llvm-svn: 359073

show more ...

Move postfix expression code out of the NativePDB plugin

Summary:
The NativePDB plugin contains code to convert "programs" describing the
layout of function frames into dwarf (for easier interaction

Move postfix expression code out of the NativePDB plugin

Summary:
The NativePDB plugin contains code to convert "programs" describing the
layout of function frames into dwarf (for easier interaction with the
rest of lldb). This functionality is useful for the Breakpad plugin too,
as it contains the same kind of expressions (because breakpad info is
generated from pdb files).

In this patch, I move the core classes of this code into a common place,
where it can be used from both files. Previously, these were the details
of the implementation, but here I am exposing them (instead of just a
single "string->string" conversion function), as breakpad will need to
use these in a slightly different way. The reason for that is that
breakpad files generated from dwarf expressions use a slightly different
syntax, although most of the core code can be reused with a bit of
thought.

This is also the reason why I am not moving the parsing or dwarf
generation bits, as they will need to be generalized a bit before
they're usable for both scenarios.

This patch should be NFC, modulo renaming the moved entities to more
neutral names.

The reason I am moving this to the "Symbol" library, is because both
customers will be "Symbol"Files, and also the unwinding code lives in
the Symbol library. From a purely dependency standpoint this code will
probably be standalone, and so it could be moved all the way to Utility,
but that seems too low for this kind of functionality.

Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov

Subscribers: aprantl, markmentovai, lldb-commits

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

llvm-svn: 358976

show more ...

Fix compiler warning introduced by r358261

Add a virtual destructor to the class with virtual methods.

llvm-svn: 358284

PDBFPO: Improvements to the AST visitor

Summary:
This patch attempts to solve two issues made this code hard to follow
for me.

The first issue was that a lot of what these visitors do is mutate the

PDBFPO: Improvements to the AST visitor

Summary:
This patch attempts to solve two issues made this code hard to follow
for me.

The first issue was that a lot of what these visitors do is mutate the
AST. The visitor pattern is not particularly good for that because by
the time you have performed the dynamic type dispatch, it's too late to
go back to the parent node, and change its pointer. The previous code
dealt with that relatively elegantly, but it still meant that one had to
perform manual type checks, which is what the visitor pattern is
supposed to avoid.

The second issue was not being able to return values from the Visit
functions, which meant that one had to store function results in member
variables (a common problem with visitor patterns).

Here, I solve both problems by making the visitor use a type switch
instead of going through double dispatch on the visited object. This
allows one to parameterize the visitor based on the return type and pass
function results as function results. The mutation is fascilitated by
having each Visit function take two arguments -- a reference to the
object itself (with the correct dynamic type), and a reference to the
parent's pointer to this object.

Although this wasn't my explicit goal here, the fact that we're not
using virtual dispatch anymore allows us to make the AST nodes
trivially destructible, which is a good thing, since we were not
destroying them anyway.

Reviewers: aleksandr.urakov, amccarth

Subscribers: lldb-commits

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

llvm-svn: 358261

show more ...

PDBFPO: add dyn_cast support

This adds the necessary glue so we can use llvm::dyn_cast, instead of
doing a manual type-check followed by a cast. NFC.

llvm-svn: 357895

PDBFPO: Use references instead of pointers, where possible

Summary:
The code was passing pointers around, expecting they would be not null.
In c++ it is possible to convey this notion explicitly by

PDBFPO: Use references instead of pointers, where possible

Summary:
The code was passing pointers around, expecting they would be not null.
In c++ it is possible to convey this notion explicitly by using a
reference instead.

Not all uses of pointers could be converted to references (e.g. one
can't store references in a container), but this will at least make it
locally obvious that code is dealing with nonnull pointers.

Reviewers: aleksandr.urakov, amccarth

Subscribers: lldb-commits

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

llvm-svn: 357744

show more ...

PDBFPO: Refactor register reference resolution

Summary:
This refactors moves the register name->number resolution out of the
FPOProgramNodeRegisterRef class. Instead I create a special
FPOProgramNod

PDBFPO: Refactor register reference resolution

Summary:
This refactors moves the register name->number resolution out of the
FPOProgramNodeRegisterRef class. Instead I create a special
FPOProgramNodeSymbol class, which holds unresolved symbols, and move the
resolution into the ResolveRegisterRefs visitor.

The background here is that I'd like to use this code for Breakpad
unwind info, which uses similar syntax to describe unwind info. For
example, a simple breakpad unwind program might look like:
.cfa: $esp 8 + $ebp: .cfa 8 - ^

To be able to do this, I need to be able to customize register
resolving, as that is presently hardcoded to use codeview register
names, but breakpad supports a lot more architectures with different
register names. Moving the resolution into a separate class will allow
each user to use a different resolution logic.

Reviewers: aleksandr.urakov, zturner, amccarth

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 357455

show more ...

[NFC] Fix license headers after r352845

llvm-svn: 353503

[PDB] Fix location retrieval for function local variables and arguments that are
stored relative to VFRAME

Summary:
This patch makes LLDB able to retrieve proper values for function arguments and
lo

[PDB] Fix location retrieval for function local variables and arguments that are
stored relative to VFRAME

Summary:
This patch makes LLDB able to retrieve proper values for function arguments and
local variables stored in PDB relative to VFRAME register.

Patch contains retrieval of corresponding FPO table entries from PDB and a
generic translator from FPO programs to DWARF expressions to get correct VFRAME
value.

Patch also improves variables-locations.test and makes this test passable on
x86.

Patch By: leonid.mashinsky

Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov

Reviewed By: zturner

Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits

Tags: #lldb

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

llvm-svn: 352845

show more ...