This adds support to LLDB for named types (class, struct, union, and
enum). This is true cross platform support, and hits the PDB file
directly without a dependency on Windows. Tests are added which
compile a program with certain interesting types and then use
load the target in LLDB and use "type lookup -- <TypeName>" to
dump the layout of the type in LLDB without a running process.
Currently only fields are parsed -- we do not parse methods. Also
we don't deal with bitfields or virtual bases correctly. Those
will make good followups.
Differential Revision: https://reviews.llvm.org/D53511
llvm-svn: 345047
This implements the support for .debug_loclists section, which is
DWARF 5 version of .debug_loc.
Currently, clang is able to emit it with the use of D53365.
Differential revision: https://reviews.llvm.org/D53436
llvm-svn: 345016
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
Some backends might violate this assumption. No test case
upstream unfortunately as this is not the case with C++,
but I'm going to add a test in swift language support.
<rdar://problem/40962410>
llvm-svn: 344982
Logs provided by @stella.stamenova indicate that on Linux, lldb adds a
spurious slide offset to the return PC it loads from AT_call_return_pc
attributes (see the list thread: "[PATCH] D50478: Add support for
artificial tail call frames").
This patch side-steps the issue by getting rid of the load address
calculation in lldb's CallEdge::GetReturnPCAddress.
The idea is to have the DWARF writer emit function-local offsets to the
instruction after a call. I.e. return-pc = label-after-call-insn -
function-entry. LLDB can simply add this offset to the base address of a
function to get the return PC.
Differential Revision: https://reviews.llvm.org/D53469
llvm-svn: 344960
As discussed with Greg at the dev meeting, we need to ensure we have the
module lock in the SymbolFile. Usually the symbol file is accessed
through the symbol vendor which ensures that the necessary locks are
taken. However, there are a few methods that are accessed by the
expression parser and were lacking the lock.
This patch adds the locking where necessary and everywhere else asserts
that we actually already own the lock.
Differential revision: https://reviews.llvm.org/D52543
llvm-svn: 344945
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
Summary: These tests fail on Windows because of known limitations (a.k.a. bugs) with the current implementation of GetFrameAtIndex
Reviewers: asmith, vsk
Reviewed By: vsk
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53415
llvm-svn: 344788
Summary: They fail similarly to some of the other breakpoint tests on Windows, so I suspect the cause is the same. I've linked to the same bug.
Reviewers: asmith, zturner, jingham
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53331
llvm-svn: 344744
Summary:
This patch makes Windows threads to compare by a thread ID, not by a handle.
It's because the same thread can have different handles on Windows
(for example, `GetCurrentThread` always returns the fake handle `-2`).
This leads to some incorrect behavior. For example, in `Process::GetRunLock`
always `m_public_run_lock` is returned without this patch.
Reviewers: zturner, clayborg, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: stella.stamenova, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53357
llvm-svn: 344729
This reverts commit r344647.
This causes build failures with [-Werror, -Wswitch]. Some cases where the newly
introduced enum value is not handled in particular are in:
lldb/source/Expression/REPL.cpp:350
lldb/source/Interpreter/CommandInterpreter.cpp:1529
(maybe there could be more)
As I don't understand lldb to make sure the likely trivial fixes are
correct and also as they might need additional tests, leaving to the
author to resolve.
llvm-svn: 344722
DWARF5 describes DW_RLE_start_end as:
This is a form of bounded range entry that has two target address operands.
Each operand is the same size as used in DW_FORM_addr. These indicate
the starting and ending addresses, respectively, that define the address range
for which the following location is valid.
The patch implements the support.
Differential revision: https://reviews.llvm.org/D53193
llvm-svn: 344674
Before we returned an error that was not exposed in the SB API and no useful
error message. This change returns eExpressionProducedNoResult and an
appropriate error string.
<rdar://problem/44539514>
Differential Revision: https://reviews.llvm.org/D53309
llvm-svn: 344647
in r344626 & recommitting. Original commit msg:
Simplify LocateDSYMInVincinityOfExecutable by moving
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344646
It merges DWARFDebugInfoEntry's m_empty_children into m_has_children.
m_empty_children was implemented by rL144983.
As Greg confirmed m_has_children was used to represent what was in the DWARF in
the byte that follows the DW_TAG. m_empty_children was used for DIEs that said
they had children but actually only contain a single NULL tag. It is fine to
not differentiate between the two.
Also changed assert()->lldbassert() for m_abbr_idx 16-bit overflow check as
that could be a tough bug to catch if it ever happens.
I have checked all calls of HasChildren() that this change should not matter to
them. The code even wants to know if there are any children - it does not
matter how the children presence is coded in the binary.
Patch written based on suggestions by Greg Clayton.
Differential Revision: https://reviews.llvm.org/D53321
llvm-svn: 344644
tests when targetting a device. Add an include to
safe-to-call-func to work around a modules issue with
a certain combination of header files. Add rules for
Darwin systems to ad-hoc codesign binaries that the
testsuite builds.
llvm-svn: 344635
The TestTailCallFrameSBAPI.py test checks that function names in a
backtrace are equal to an expected value.
Use a relaxed substring check because function dislpay names are
platform-dependent. E.g we see "void sink(void)" on Windows, but "sink()" on
Darwin. This seems like a bug -- just work around it for now.
llvm-svn: 344634
which PlatformRemoteDarwinDevice::UpdateSDKDirectoryInfosIfNeeded
which examine for any additional SDK directories when it is
constructing its list.
<rdar://problem/42984340>
<rdar://problem/41351223>
llvm-svn: 344628
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344626
Summary: On non-mac platforms, mac_ver returns an empty string which when converted to LooseVersion has no "version" property. This causes a failure when the decorator executes. Instead, check whether the value returned from mac_ver is an empty string and avoid the LooseVersion comparison.
Reviewers: labath, davide, asmith, shafik, jingham
Reviewed By: jingham
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D53208
llvm-svn: 344623
xbolva00 bugreported $subj in: https://reviews.llvm.org/D46810#1247410
It can happen only from the line:
m_die_array.back().SetEmptyChildren(true);
In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of
list, no children present). Therefore the assertion can fortunately happen only
with a hand-crafted DWARF or with DWARF from some suboptimal compilers.
Differential Revision: https://reviews.llvm.org/D53255
llvm-svn: 344605
Some tests in test/functionalities/tail_call_frames are failing on
non-Darwin platforms. Use assertEqual to improve logging on failure.
llvm-svn: 344581
Summary:
If the names are not unique, the tests overwrite each other's results and logs. This also causes failures on platforms where the files are locked for writing.
The names of the class/test pairs *have to* always be unique. The easiest way to achieve that is to name each class differently (usually the same as the file name).
Reviewers: jasonmolenda, asmith
Subscribers: clayborg, nemanjai, kbarton, lldb-commits
Differential Revision: https://reviews.llvm.org/D53297
llvm-svn: 344547
Summary: This test is failing on Windows because lldb does not support JIT on Windows.
Reviewers: davide, asmith
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53226
llvm-svn: 344543
Fix llvm.org/pr39054:
- Register _lldb as a built-in module during initialization of script interpreter,
- Reverse the order of imports in __init__.py: first try to import by absolute name, which will find the built-in module in the context of lldb (and other hosts that embed liblldb), then try relative import, in case the module is being imported from Python interpreter.
This works for SWIG>=3.0.11; before that, SWIG did not support custom module import code.
Differential revision: https://reviews.llvm.org/D52404
llvm-svn: 344474
This adds -- before any filenames, so that /U doesn't get interpreted
as a command line.
It also adds better error checking, so that we don't get assertions
on the failure path when a file fails to parse as a PDB.
llvm-svn: 344429
If the path was not specified (and it's None), lexists throws an exception rather than returning False. get_filecheck_path now checks whether filecheck is set before calling lexists
llvm-svn: 344410
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 allows bots which haven't updated to pass in --filecheck to
dotest.py to run more tests. FileCheck-dependent tests will continue to
fail.
Differential Revision: https://reviews.llvm.org/D53175
llvm-svn: 344401
Summary: This is another string/byte conversion issue between Python 2 and 3. In Python 2, the subprocess communication expects a byte string, but in Python 3, it expects bytes. Since both versions are capable of using strings when universal_newlines is set to True AND filecheck operates on strings, force the use of strings.
Reviewers: zturner, asmith, vsk
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53166
llvm-svn: 344386
LLDB does not support this DWARF5 form atm.
At least gcc emits it in some cases when doing optimization
for abbreviations.
As far I can tell, clang does not support it yet, though
the rest LLVM code already knows about it.
The patch adds the support.
Differential revision: https://reviews.llvm.org/D52689
llvm-svn: 344328
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
Jason Molenda