This fixes (one aspect of) compilation of LLDB with MSVC for ARM64.
LLDB source files include intrin.h, and the MSVC intrin.h transitively
includes arm64intr.h, which has an ARM64_FPSR define, which clashes
with the enum declaration.
Differential Revision: https://reviews.llvm.org/D67864
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372481 91177308-0d34-0410-b5e6-96231b3b80d8
Add the core registers and NEON registers mapping to the CodeView
register ID. This is sufficient to compile a basic C program with debug
info using CodeView debug info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@370423 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@369013 91177308-0d34-0410-b5e6-96231b3b80d8
Some versions of the Visual C++ 2015 runtime have line tables with the
subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to
be DEBUG_S_IGNORE. This appears to implement the intended behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363724 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Fixes inline call frame line table display in windbg.
- Improve llvm-pdbutil to dump extra file ids.
- Warn on unknown subsections so we don't have this kind of bug in the
future.
Reviewers: inglorion, akhuang, aganea
Subscribers: eraman, zturner, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62701
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362429 91177308-0d34-0410-b5e6-96231b3b80d8
CodeView has its own register map which is defined in cvconst.h. Missing this
mapping before saving register to CodeView causes debugger to show incorrect
value for all register based variables, like variables in register and local
variables addressed by register (stack pointer + offset).
This change added mapping between LLVM register and CodeView register so the
correct register number will be stored to CodeView/PDB, it aso fixed the
mapping from CodeView register number to register name based on current
CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed.
Differential Revision: https://reviews.llvm.org/D62608
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362280 91177308-0d34-0410-b5e6-96231b3b80d8
This ports and improves on some existing llvm-readobj -codeview dumping
functionality that llvm-pdbutil lacked.
Helpful for comparing inline line tables between MSVC and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362037 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Now CVType and CVSymbol are effectively type-safe wrappers around
ArrayRef<uint8_t>. Make the kind() accessor load it from the
RecordPrefix, which is the same for types and symbols.
Reviewers: zturner, aganea
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357658 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Swift now generates PDBs for debugging on Windows. llvm and lldb
need a language enumerator value too properly handle the output
emitted by swiftc.
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59231
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355882 91177308-0d34-0410-b5e6-96231b3b80d8
When type streams with forward references were merged using GHashes, cycles
were introduced in the debug info. This was caused by
GlobalTypeTableBuilder::insertRecordAs() not inserting the record on the second
pass, thus yielding an empty ArrayRef at that record slot. Later on, upon PDB
emission, TpiStreamBuilder::commit() would skip that empty record, thus
offseting all indices that came after in the stream.
This solution comes in two steps:
1. Fix the hash calculation, by doing a multiple-step resolution, iff there are
forward references in the input stream.
2. Fix merge by resolving with multiple passes, therefore moving records with
forward references at the end of the stream.
This patch also adds support for llvm-readoj --codeview-ghash.
Finally, fix dumpCodeViewMergedTypes() which previously could reference deleted
memory.
Fixes PR40221
Differential Revision: https://reviews.llvm.org/D57790
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353412 91177308-0d34-0410-b5e6-96231b3b80d8
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would create an lldb::Function object for each function
parsed, but we would not add these to the clang AST. This is a first
step towards getting local variable support working, as we first need an
AST decl so that when we create local variable entries, they have the
proper DeclContext.
Differential Revision: https://reviews.llvm.org/D55384
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348631 91177308-0d34-0410-b5e6-96231b3b80d8
This is no longer used and is just taking up space in the structure.
Heap allocation of this structure is on the critical path, so space
actually matters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348318 91177308-0d34-0410-b5e6-96231b3b80d8
When you have a member function with a ref-qualifier, for example:
struct Foo {
void Func() &;
void Func2() &&;
};
clang-cl was not emitting this information. Doing so is a bit
awkward, because it's not a property of the LF_MFUNCTION type, which
is what you'd expect. Instead, it's a property of the this pointer
which is actually an LF_POINTER. This record has an attributes
bitmask on it, and our handling of this bitmask was all wrong. We
had some parts of the bitmask defined incorrectly, but importantly
for this bug, we didn't know about these extra 2 bits that represent
the ref qualifier at all.
Differential Revision: https://reviews.llvm.org/D54667
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347354 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347018 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346429 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345848 91177308-0d34-0410-b5e6-96231b3b80d8
The TypeIndex used by cl.exe is 0x103, which indicates a SimpleTypeMode
of NearPointer (note the absence of the bitness, normally pointers use a
mode of NearPointer32 or NearPointer64) and a SimpleTypeKind of void.
So this is basically a void*, but without a specified size, which makes
sense given how std::nullptr_t is defined.
clang-cl was actually not emitting *anything* for this. Instead, when we
encountered std::nullptr_t in a DIType, we would actually just emit a
TypeIndex of 0, which is obviously wrong.
std::nullptr_t in DWARF is represented as a DW_TAG_unspecified_type with
a name of "decltype(nullptr)", so we add that logic along with a test,
as well as an update to the dumping code so that we no longer print
void* when dumping 0x103 (which would previously treat Void/NearPointer
no differently than Void/NearPointer64).
Differential Revision: https://reviews.llvm.org/D53957
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345811 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344913 91177308-0d34-0410-b5e6-96231b3b80d8
