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.
This patch writes a mapping structure for converting CodeView Arm64 register numbers to LLDB Arm64 regnums.
This fixes various symbols and variable location test failures on AArch64/Windows.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D128221
On Windows, when compile with -fdebug-compilation-dir which contains slash, the source file path in PDB will look like "../tmp\file.cc" because the path separator used is determined by target machine. Converting backslash to slash helps lldb to find the CU in ResolveSymbolContext.
We want to filter out CU with no function in ResolveSymbolContext as a cpp file will have two debug info modules in PDB if built with thinlto and one of them is a skeleton with no function 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.
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
- Don't reset cur_line_offset to llvm::None when we don't have next_line_offset, because we may need to reuse it in new range after a code end.
- Don't use CombineConsecutiveEntriesWithEqualData for inline_site_sp->ranges, because that will combine consecutive entries with same data in the vector regardless of the entry's range. Originally, I thought that it only combine consecutive entries if adjacent entries' ranges are adjoining or intersecting with each other.
Previously, I was assuming that S_DEFRANGE_SUBFIELD_REGISTERs are always in the
increasing order of offset_in_parent until I saw a counter example.
Using `std::map` so that they are sorted by offset_in_parent.
Differential Revision: https://reviews.llvm.org/D124061
When a variable is simple type and has 64 bits, the debug info may look like the following when targeting 32bit windows. The variable's content is split into two 32bits registers.
```
480 | S_LOCAL [size = 12] `x`
type=0x0013 (__int64), flags = param
492 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = EAX, may have no name = true, offset in parent = 0
range = [0001:0073,+7), gaps = []
512 | S_DEFRANGE_SUBFIELD_REGISTER [size = 20]
register = ECX, may have no name = true, offset in parent = 4
range = [0001:0073,+7), gaps = []
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D122943
It fixes the following case:
```
0602 line 1 (+1)
0315 code 0x15 (+0x15)
0B2B code 0x20 (+0xB) line 2 (+1)
0602 line 3 (+1)
0311 code 0x31 (+0x11)
...
```
Inline ranges should have following mapping:
`[0x15, 0x20) -> line 1`
`[0x20, 0x31) -> line 2`
Inline line entries:
`0x15, line 1`, `0x20, line 2`, `0x31, line 3`.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D123092
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
`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
D115300 added Rust as a new PDB language type.
This change allows LLDB to recognize the new language type.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D119044
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
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
This adds inline function support to NativePDB by parsing S_INLINESITE records
to retrieve inlinee line info and add them into line table at `ParseLineTable`.
Differential Revision: https://reviews.llvm.org/D116845
This is a split of D113724. Calling `TypeSystemClang::AddMethodToCXXRecordType`
to create function decls for class methods.
Differential Revision: https://reviews.llvm.org/D113930
I don't see a reason why not to. If we allows lookup functions by full names,
I can change the test case in D113930 to use `lldb-test symbols --find=function --name=full::name --function-flags=full ...`,
though the duplicate method decl prolem is still there for `lldb-test symbols --dump-ast`.
That's a seprate bug, we can fix it later.
Differential Revision: https://reviews.llvm.org/D114467
`image lookup -a ` doesn't work because the compilands list is always empty.
Create CU at given index if doesn't exit.
Differential Revision: https://reviews.llvm.org/D113821
