Previously, lldb mistook fields in anonymous union in a struct as the direct
field of the struct, which causes lldb crashes due to multiple fields sharing
the same offset in a struct. This patch fixes it.
MSVC generated pdb doesn't have the debug info entity representing a anonymous
union in a struct. It looks like the following:
```
struct S {
union {
char c;
int i;
};
};
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
```
Clang generated pdb is similar, though due to the [[ https://github.com/llvm/llvm-project/issues/57999 | bug ]],
it's not more useful than the debug info above. But that's not very relavent,
lldb should still be able to understand MSVC geneerated pdb.
```
0x1003 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: <no type>
options: forward ref (= 0x1003) | has unique name | is nested, sizeof 0
0x1004 | LF_FIELDLIST [size = 40]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
- LF_NESTTYPE [name = ``, parent = 0x1003]
0x1005 | LF_STRUCTURE [size = 32] `S`
unique name: `.?AUS@@`
vtable: <no type>, base list: <no type>, field list: 0x1004
options: contains nested class | has unique name, sizeof 4
0x1006 | LF_FIELDLIST [size = 28]
- LF_MEMBER [name = `c`, Type = 0x0070 (char), offset = 0, attrs = public]
- LF_MEMBER [name = `i`, Type = 0x0074 (int), offset = 0, attrs = public]
0x1007 | LF_UNION [size = 60] `S::<unnamed-tag>`
unique name: `.?AT<unnamed-type-$S1>@S@@`
field list: 0x1006
options: has unique name | is nested | sealed, sizeof
```
This patch delays the FieldDecl creation when travesing LF_FIELDLIST so we know
if there are multiple fields are in the same offsets and are able to group them
into different anonymous unions based on offsets. Nested anonymous union will
be flatten into one anonymous union, because we simply don't have that info, but
they are equivalent in terms of union layout.
Differential Revision: https://reviews.llvm.org/D134849
If we don't add local variables with no location info, when trying to print it,
lldb won't find it in the its parent DeclContext, which makes lldb to spend more
time to search all the way up in DeclContext hierarchy until found same name
variable or failed. Dwarf plugin also add local vars even if they don't have
location info.
Differential Revision: https://reviews.llvm.org/D133626
Before, NativePDB uses scoped range as a workaround for value range, that causes
problems (e.g. a variable's value can only have one range, but usually a
variable's value is located at different address ranges, each at different
locations, in optimized build).
This patch let NativePDB switch to DWARFLocationList so a variable's value can
be described at multiple non-overlapped address ranges and each range maps to a
location.
Because overlapping ranges exists, here's peference when choosing ranges:
1. Always prefer whole value locations. Suppose a variable size is 8 bytes, one record is that for range [1, 5) first 4 bytes is at ecx, and another record is that for range [2, 8) the 8 bytes value is at rdx. This results: [1, 2) has first 4 bytes at ecx, [2, 8) has the whole value at rdx.
2. Always prefer the locations parsed later. Suppose first record is that for range [1, 5) value is at ecx, second record is that for range [2, 6) value is at eax. This results: [1, 2) -> ecx, [2, 6) -> eax.
Differential Revision: https://reviews.llvm.org/D130796
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.
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.
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
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
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
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
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.
llvm-svn: 351636
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types" are actually represented as
"symbols", so they need special handling.
In order to test this, we don't just use lldb and print out some
variables causing the AST to get created, because variables whose type
is a typedef will have debug info referencing the original type, not the
typedef. So we use lldb-test instead which will parse all debug info in
the entire file. This exposed some problems with lldb-test and the
native reader, mainly that certain types of obscure symbols which we can
find when iterating every single record would trigger crashes. These
have been fixed as well so that lldb-test can be used to test this
functionality.
Differential Revision: https://reviews.llvm.org/D56461
llvm-svn: 350888
This is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, which is
that the plugin expects that ParseDeclsForContext will also
create lldb symbols rather than just the decls, but the native
pdb plugin doesn't currently do this. This will be addressed
in a followup patch.
llvm-svn: 350243
Previously we would create these for local variables but not for
global variables.
Also updated existing tests which created global variables to check
for them in the resulting AST.
llvm-svn: 349854
Previously the code that parsed debug info to create lldb's Symbol
objects such as Variable, Type, Function, etc was tightly coupled
to the AST reconstruction code. This made it difficult / impossible
to implement functions such as ParseDeclsForContext() that were only
supposed to be operating on clang AST's. By splitting these apart,
the logic becomes much cleaner and we have a clear separation of
responsibilities.
llvm-svn: 349383
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
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
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
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
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
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
This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.
llvm-svn: 344279
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
Zequan Wu