[LLDB][NativePDB] Add MSInheritanceAttr when creating pointer type that is a pointer to member.

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

[CodeView] Call llvm::codeview::visitMemberRecordStream with the deserialized CVType whose kind is FieldListRecord.

llvm::codeview::visitMemberRecordStream expects to receive an array ref that's Fie

[CodeView] Call llvm::codeview::visitMemberRecordStream with the deserialized CVType whose kind is FieldListRecord.

llvm::codeview::visitMemberRecordStream expects to receive an array ref that's FieldListRecord's Data not a CVType's data which has 4 more bytes preceeding. The first 2 bytes indicate the size of the FieldListRecord, and following 2 bytes is always 0x1203. Inside llvm::codeview::visitMemberRecordStream, it iterates to the data to check if first two bytes matching some type record kinds. If the size coincidentally matches one type kind, it will start parsing from there and causing crash.

show more ...

Don't use Optional::getValue (NFC)

Don't use Optional::hasValue (NFC)

[LLDB][NativePDB] Fix several crashes when parsing debug info.
1. If array element type is a tag decl, complete it.
2. Fix few places where `asTag` should be used instead of `asClass()`.
3. Handle th

[LLDB][NativePDB] Fix several crashes when parsing debug info.
1. If array element type is a tag decl, complete it.
2. Fix few places where `asTag` should be used instead of `asClass()`.
3. Handle the case that `PdbAstBuilder::CreateFunctionDecl` return nullptr mainly due to an existing workaround (`m_cxx_record_map`).
4. `FindMembersSize` should never return error as this would cause early exiting in `CVTypeVisitor::visitFieldListMemberStream` and then cause assertion failure.
5. In some pdbs from C++ runtime libraries have S_LPROC32 followed directly by S_LOCAL and the local variable location is a S_DEFRANGE_FRAMEPOINTER_REL. There is no information about base frame register in this case, ignoring it by returning RegisterId::NONE.
6. Add a TODO when S_DEFRANGE_SUBFIELD_REGISTER describes the variable location of a pointer type. For now, just ignoring it if the variable is pointer.

show more ...

[LLDB][NativePDB] Check for missing type info to avoid crash.

NativePDB often assumes that all debug info are available.
This is one step to make it more pervasive.

Differential Revision: https://r

[LLDB][NativePDB] Check for missing type info to avoid crash.

NativePDB often assumes that all debug info are available.
This is one step to make it more pervasive.

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

show more ...

[LLDB][NativePDB] Make sure the number of param symbol records is the same as the number get from function type record before setting parameters.

[LLDB][NativePDB] Followup c50817d1bea4ac51ed776154014630a439176de6

[LLDB][NativePDB] Don't create inlined function parameters when it's malformed.

[LLDB][NativePDB] Create inline function decls

This creates inline functions decls in the TUs where the funcitons are inlined and local variable decls inside those functions.

Reviewed By: labath

D

[LLDB][NativePDB] Create inline function decls

This creates inline functions decls in the TUs where the funcitons are inlined and local variable decls inside those functions.

Reviewed By: labath

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

show more ...

[LLDB][NativePDB] Don't complete static members' types when completing a record type.

`UdtRecordCompleter` shouldn't complete static members' types. static members' types are going to be completed w

[LLDB][NativePDB] Don't complete static members' types when completing a record type.

`UdtRecordCompleter` shouldn't complete static members' types. static members' types are going to be completed when the types are called in `SymbolFile::CompleteType`.

Reviewed By: labath

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

show more ...

[LLDB][NativePDB] Add support for S_DEFRANGE_REGISTER and S_DEFRANGE_SUBFIELD_REGISTER

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

[LLDB][NativePDB] fix that FindSymbolScope never finds scope of a symbol if it doesn't open a scope

[lldb] PdbAstBuilder - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

The pointers are dereferenced immediately, so assert the cast is correct instead of returning nullptr

Use isa instead of dyn_cast (NFC)

[LLDB][NativePDB] Fix function decl creation for class methods

This is a split of D113724. Calling `TypeSystemClang::AddMethodToCXXRecordType`
to create function decls for class methods.

Differenti

[LLDB][NativePDB] Fix function decl creation for class methods

This is a split of D113724. Calling `TypeSystemClang::AddMethodToCXXRecordType`
to create function decls for class methods.

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

show more ...

[lldb][NFC] StringRef-ify the name parameter in CreateEnumerationType

Reviewed By: labath

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

[lldb] Allow dumping the state of all scratch TypeSystems

This adds the `target dump typesystem'`command which dumps the TypeSystem of the
target itself (aka the 'scratch TypeSystem'). This is simil

[lldb] Allow dumping the state of all scratch TypeSystems

This adds the `target dump typesystem'`command which dumps the TypeSystem of the
target itself (aka the 'scratch TypeSystem'). This is similar to `target modules
dump ast` which dumps the AST of lldb::Modules associated with a selected
target.

Unlike `target modules dump ast`, the new command is not a subcommand of `target
modules dump` as it's not touching the modules of a target at all. Also unlike
`target modules dump ast` I tried to keep the implementation language-neutral,
so this patch moves our Clang `Dump` to the `TypeSystem` interface so it will
also dump the state of any future/downstream scratch TypeSystems (e.g., Swift).
That's also why the command just refers to a 'typesystem' instead of an 'ast'
(which is only how Clang is necessarily modelling the internal TypeSystem
state).

The main motivation for this patch is that I need to write some tests that check
for duplicates in the ScratchTypeSystemClang of a target. There is currently no
way to check for this at the moment (beside measuring memory consumption of
course). It's probably also useful for debugging LLDB itself.

Reviewed By: labath

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

show more ...

[lldb][NFC] Use ArrayRef in TypeSystemClang::SetFunctionParameters

The implementation converts the pointer/size pair anyway back to ArrayRef.

[lldb] Unify the two CreateTypedef implementations in TypeSystemClang

To get LLDB one step closer to fulfil the software redundancy requirements of
modern aircrafts, we apparently decided to have tw

[lldb] Unify the two CreateTypedef implementations in TypeSystemClang

To get LLDB one step closer to fulfil the software redundancy requirements of
modern aircrafts, we apparently decided to have two separately maintained
implementations of `CreateTypedef` in TypeSystemClang. Let's pass on the idea of
an LLDB-powered jetliner and deleted one implementation.

On a more serious note: This function got duplicated a long time ago when the
idea of CompilerType with a backing TypeSystemClang subclass happened
(56939cb31061d24ae3d1fc62da38b57e78bb2556). One implementation was supposed to
be called from CompilerType::CreateTypedef and the other has just always been
around to create typedefs. By accident one of the implementations is only used
by the PDB parser while the CompilerType::CreateTypedef backend is used by the
rest of LLDB.

We also had some patches over the year that only fixed one of the two functions
(D18099 for example only fixed up the CompilerType::CreateTypedef
implementation). D51162 and D86140 both fixed the same missing `addDecl` call
for one of the two implementations.

This patch:
* deletes the `CreateTypedefType` function as its only used by the PDB parser
and the `CreateTypedef` implementation is anyway needed as it's the backend
implementation of CompilerType.
* replaces the calls in the PDB parser by just calling the CompilerType wrapper.
* moves the documentation to the remaining function.
* moves the check for empty typedef names that was only in the deleted
implementation to the other (I don't think this fixes anything as I believe
all callers are already doing the same check).

I'll fix up the usual stuff (not using StringRef, not doing early exit) in a NFC
follow-up.

This patch is not NFC as the PDB parser now calls the function that has the fix
from D18099.

Reviewed By: labath, JDevlieghere

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

show more ...

[lldb][NFC] Use StringRef in CreateFunctionDeclaration/GetDeclarationName

CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is
(only) used by CreateFunctionDeclaration so th

[lldb][NFC] Use StringRef in CreateFunctionDeclaration/GetDeclarationName

CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is
(only) used by CreateFunctionDeclaration so that's why now also takes a
StringRef.

show more ...

[lldb][PDB] Constexpr static member values as AST literals

Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify

[lldb][PDB] Constexpr static member values as AST literals

Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.

Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.

This change applies to DIA and native PDB loaders.

Patch By: jackoalan

Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor

Reviewed By: aleksandr.urakov

Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb

Tags: #lldb, #llvm

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

show more ...

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarch

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.

rdar://problem/59634380

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

show more ...

Revert "Preserve the owning module information from DWARF in the synthesized AST"

This reverts commit 4354dfbdf5c8510a7ddff10ae67a28e16cf7cc79 while investigating bot fallout.

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarch

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

rdar://problem/59634380

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

show more ...