This adds the support for DW_FORM_addrx, DW_FORM_addrx1,
DW_FORM_addrx2, DW_FORM_addrx3, DW_FORM_addrx4 forms.
Differential revision: https://reviews.llvm.org/D53813
llvm-svn: 345706
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
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
Summary:
This patch fixes issues with a stack realignment.
MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one
is used for access to function parameters, while another is used for access to
locals. To support this the patch:
- adds an alternative frame pointer (`ebx`);
- considers stack realignment instructions (e.g. `and esp, -32`);
- along with CFA (Canonical Frame Address) which point to the position next to
the saved return address (or to the first parameter on the stack) introduces
AFA (Aligned Frame Address) which points to the position of the stack pointer
right after realignment. AFA is used for access to registers saved after the
realignment (see the test);
Here is an example of the code with the realignment:
```
struct __declspec(align(256)) OverAligned {
char c;
};
void foo(int foo_arg) {
OverAligned oa_foo = { 1 };
auto aaa_foo = 1234;
}
void bar(int bar_arg) {
OverAligned oa_bar = { 2 };
auto aaa_bar = 5678;
foo(1111);
}
int main() {
bar(2222);
return 0;
}
```
and here is the `bar` disassembly:
```
push ebx
mov ebx, esp
sub esp, 8
and esp, -100h
add esp, 4
push ebp
mov ebp, [ebx+4]
mov [esp+4], ebp
mov ebp, esp
sub esp, 200h
mov byte ptr [ebp-200h], 2
mov dword ptr [ebp-4], 5678
push 1111 ; foo_arg
call j_?foo@@YAXH@Z ; foo(int)
add esp, 4
mov esp, ebp
pop ebp
mov esp, ebx
pop ebx
retn
```
Reviewers: labath, zturner, jasonmolenda, stella.stamenova
Reviewed By: jasonmolenda
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53435
llvm-svn: 345577
Only attempt to link against Backtrace if it is found. Without this,
trying to cross-compile to Windows would try to link against
"Backtrace_LIBRARY-NOTFOUND.lib".
llvm-svn: 345569
Summary:
When evaluating expressions the generic arguments registers are required by ABI.
This patch defines them.
Reviewers: zturner, stella.stamenova, labath
Subscribers: aleksandr.urakov, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53753
llvm-svn: 345385
LLDB has the ability to display global variables, even without a running
process, via the target variable command. This is because global
variables are linker initialized, so their values are embedded directly
into the executables. This gives us great power for testing native PDB
functionality in a cross-platform manner, because we don't actually need
a running process. We can just create a target using an EXE file, and
display global variables. And global variables can have arbitrarily
complex types, so in theory we can fully exercise the type system,
record layout, and data formatters for native PDB files and PE/COFF
executables on any host platform, as long as our type does not require a
dynamic initializer.
This patch adds basic support for finding variables by name, and adds an
exhaustive test for fundamental data types and pointers / references to
fundamental data types.
Subsequent patches will extend this to typedefs, classes, pointers to
functions, and other cases.
Differential Revision: https://reviews.llvm.org/D53731
llvm-svn: 345373
For the reproducer feature I need to be able to export and import the
current LLDB configuration. To realize this I've extended the existing
functionality to print settings. With the help of a new formatting
option, we can now write the settings and their values to a file
structured as regular commands.
Concretely the functionality works as follows:
(lldb) settings export -f /path/to/file
This file contains a bunch of settings set commands, followed by the
setting's name and value.
...
settings set use-external-editor false
settings set use-color true
settings set auto-one-line-summaries true
settings set auto-indent true
...
You can import the settings again by either sourcing the file or using
the settings read command.
(lldb) settings read -f /path/to/file
Differential revision: https://reviews.llvm.org/D52651
llvm-svn: 345346
This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.
Differential Revision: https://reviews.llvm.org/D53616
llvm-svn: 345314
When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with. We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with. This way the person reading the code just knows what it is.
The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum. This should address all
the mechanical issues surrounding using rich enum types directly.
This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.
Differential Revision: https://reviews.llvm.org/D53597
llvm-svn: 345313
We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses. Every single caller
followed this exact 2-step process, and there was manual memory
management going on with raw pointers. We can do better than this
by storing a vector of unique_ptrs and passing this around.
This makes for a cleaner API, and we only need to call one method
so there is no possibility of a user forgetting to call
DeleteBaseClassSpecifiers.
In addition to this, it also makes for a *simpler* API. Part of
why I wanted to do this is because when I was implementing the native
PDB interface I had to spend some time understanding exactly what I
was deleting and why. ClangAST has significant mental overhead
associated with it, and reducing the API surface can go along
way to making it simpler for people to understand.
Differential Revision: https://reviews.llvm.org/D53590
llvm-svn: 345312
This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889. VersionTuple::tryParse() can deal
with an optional third (micro) component, but the parse will fail when
there are extra characters after the version number (e.g.: trying to
parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails
after that patch). Fixed here by stripping the ".sdk" suffix first.
(Part of) rdar://problem/45041492
Differential Revision https://reviews.llvm.org/D53677
llvm-svn: 345274
With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was
omited/forgotten/removed by mistake.
Original commit message:
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
----
Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml
Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
llvm-svn: 345251
Currently, we always parse the length field of DW_LLE_startx_length entry as U32.
That is correct for pre-standard definition:
https://gcc.gnu.org/wiki/DebugFission - "A start/length entry contains one unsigned LEB128 number
and a 4-byte unsigned value (as would be represented by the form code DW_FORM_const4u). The first
number is an index into the .debug_addr section that selects the beginning offset, and the second
number is the length of the range. ")
But DWARF v5 says: "This is a form of bounded location description that has two unsigned ULEB operands.
The first value is an address index (into the .debug_addr section) that indicates the beginning of the address
range over which the location is valid. The second value is the length of the range."
Fortunately, we can easily handle the difference. No test case because it seems impossible to test
until we will be ready to use DWARF v5 in tests that need to run the executables.
Differential revision: https://reviews.llvm.org/D53646
llvm-svn: 345249
The -force option allows you to pass an empty value to settings set to
reset the value to its default. This means that the following operations
are equivalent:
settings set -f <setting>
settings clear <setting>
The motivation for this change is the ability to export and import
settings from LLDB. Because of the way the dumpers work, we don't know
whether a value is going to be the default or not. Hence we cannot use
settings clear and use settings set -f, potentially providing an empty
value.
Differential revision: https://reviews.llvm.org/D52772
llvm-svn: 345207
The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair
.debug_rnglists entries
Differential revision: https://reviews.llvm.org/D53140
llvm-svn: 345127
Add support in ProcessGDBRemote::GetGDBServerRegisterInfo
for recognizing a generic "arm" architecture that will be used if
nothing better is available so that we don't ignore the register
definitions if we didn't already have an architecture set.
Also in ProcessGDBRemote::DoConnectRemote don't set the target
arch unless we have a valid architecture to set it to.
Platform::ConnectProcess will try to get the current target's
architecture, or the default architecture, when creating the
target for the connection to be attempted. If lldb was started
with a target binary, we want to create this target with that
architecture in case the remote gdb stub doesn't supply a
qHostInfo arch.
Add logging to Target::MergeArchitecture.
<rdar://problem/34916465>
llvm-svn: 345106
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:
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
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
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
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
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
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
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344269
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
Summary:
If the process exits before any initial stop then notify the debugger
of the error otherwise WaitForDebuggerConnection() will be blocked.
An example of this issue is when a process fails to load a dependent DLL.
In addition to the fix, remove a duplicate call to FreeProcessHandles() in
DebuggerThread::HandleExitProcessEvent() and use decimal format
for all thread IDs.
Reviewers: rnk, zturner, aleksandr.urakov
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53090
llvm-svn: 344168
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
There are several places that call `FindRanges`,
all of them use `Slide` to adjust the ranges found
by the base address.
All except one, which does the same manually in a loop.
Patch updates it to use `Slide` for consistency.
llvm-svn: 344122
This adds a basic support of the .debug_rnglists section.
Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported.
Differential revision: https://reviews.llvm.org/D52981
llvm-svn: 344119
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
Summary:
Add settings to control command echoing:
```
(lldb) settings set interpreter.echo-commands true
(lldb) settings set interpreter.echo-comment-commands true
```
Both settings default to true, which keeps LLDB's existing behavior in non-interactive mode (echo all command inputs to the output).
So far the only way to change this behavior was the `--source-quietly` flag, which disables all output including evaluation results.
Now `echo-commands` allows to turn off echoing for commands, while evaluation results are still printed. No effect if `--source-quietly` was present.
`echo-comment-commands` allows to turn off echoing for commands in case they are pure comment lines. No effect if `echo-commands` is false.
Note that the behavior does not change immediately! The new settings take effect only with the next command source.
LLDB lit test are the main motivation for this feature. So far incoming `#CHECK` line have always been echoed to the output and so they could never fail. Now we can disable it in lit-lldb-init.
Todos: Finish test for this feature. Add to lit-lldb-init. Check for failing lit tests.
Reviewers: aprantl, jasonmolenda, JDevlieghere
Subscribers: friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D52788
llvm-svn: 343859
Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.
Therefore I move it to the base class.
Reviewers: krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52719
llvm-svn: 343683
This is a follow-up to https://reviews.llvm.org/D46362.
When evaluating a complex expression in DWARFExpression::Evaluate,
file addresses must be resolved to load addresses before we can
perform operations such as DW_OP_deref on them.
For this the address goes through three steps
1. Read the file address as stored in the DWARF
2. Link/relocate the file address (when reading from a .dSYM, this is a no-op)
3. Convert the file address to a load address.
D46362 implemented step (3) by resolving the file address using the
Module that the original DWARF came from. In the case of a dSYM that
is correct, but when reading from .o files, we need to look up
relocated/linked addresses, so the right place to look them up is the
current frame's module. This patch fixes that by setting the
expression's Module to point to the linked debugmap object.
A word a bout the unorthodox testcase: The motivating testcase for
this fix is in Swift, but I managed to hand-modify LLVM-IR for a
trivial C program to exhibit the same problem, so we can fix this in
llvm.org.
rdar://problem/44689915
Differential Revision: https://reviews.llvm.org/D52678
llvm-svn: 343612
Summary:
If there is no newline the "lldb" prompt could be on the wrong line. To reproduce the missing newline you can do 'image dump smytab' on any binary.
Previously
Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0(lldb)
Now
Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0
(lldb)
Reviewers: zturner, aleksandr.urakov, lldb-commits
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D52627
llvm-svn: 343497
Currently we reject our own default disassembly-format string because it
contains two backticks which causes everything in between to be
interpreter as an expression by the command interpreter. This patch
fixes that by escaping backticks when dumping format strings.
llvm-svn: 343471
Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).
(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.
Reviewers: krytarowski, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52532
llvm-svn: 343409
Summary:
The `ClangUserExpression::GetLanguageForExpr` method is currently a big
source of sadness, as it's name implies that it's an accessor method, but it actually
is also initializing some variables that we need for parsing. This caused that we
currently call this getter just for it's side effects while ignoring it's return value,
which is confusing for the reader.
This patch renames it to `UpdateLanguageForExpr` and merges all calls to the
method into a single call in `ClangUserExpression::PrepareForParsing` (as calling
this method is anyway mandatory for parsing to succeed)
While looking at the code, I also found that we actually have two language
variables in this class hierarchy. The normal `Language` from the UserExpression
class and the `LanguageForExpr` that we implemented in this subclass. Both
don't seem to actually contain the same value, so we probably should look at this
next.
Reviewers: xbolva00
Reviewed By: xbolva00
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52561
llvm-svn: 343191
Summary:
This patch implements restoring of the calling convention from PDB.
It is necessary for expressions evaluation, if we want to call a function
of the debuggee process with a calling convention other than ccall.
Reviewers: clayborg, zturner, labath, asmith
Reviewed By: clayborg
Subscribers: teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52501
llvm-svn: 343084
NativeProcessProtocol::ReadMemoryWithoutTrap had a bug, where it failed
to properly remove inserted breakpoint opcodes if the memory read
partially overlapped the trap opcode. This could not happen on x86
because it has a one-byte breakpoint instruction, but it could happen on
arm, which has a 4-byte breakpoint instruction (in arm mode).
Since triggerring this condition would only be possible on an arm
machine (and even then it would be a bit tricky). I test this using a
NativeProcessProtocol unit test.
llvm-svn: 343076
max number of stack frames to backtrace, make it a setting,
target.process.thread.max-backtrace-depth.
Add a test case for the setting.
<rdar://problem/28759559>
llvm-svn: 343029
AbsPosToLineColumnPos is the only reader of m_user_expression_start_pos
and actually treats it like a size_t. Also the value we store in
m_user_expression_start_pos is originally a size_t, so it makes sense
to change the type of this variable to size_t.
llvm-svn: 342804
When creating a target, lldb loads all dependent files (i.e. libs in
LC_LOAD_DYLIB for Mach-O). This can be confusing, especially when two
versions of the same library end up in the shared cache. It's possible
to change this behavior, by specifying target create -d <target> these
dependents are not loaded.
This patch changes the default behavior to only load dependent files
only when the target is an executable. When creating a target for a
library, it is now no longer necessary to pass -d. The user can still
override this behavior by specifying the -d option to change this
behavior.
rdar://problem/43721382
Differential revision: https://reviews.llvm.org/D51934
llvm-svn: 342634
This is an NFC commit to refactor the "load dependent files" parameter
from a boolean to an enum value. We want to be able to specify a
default, in which case we decide whether or not to load the dependent
files based on whether the target is an executable or not (i.e. a
dylib).
This is a dependency for D51934.
Differential revision: https://reviews.llvm.org/D51859
llvm-svn: 342633
Summary:
Completing inside the expression command now uses the new description API
to also provide additional information to the user. For now this information
are the types of variables/fields and the signatures of completed function calls.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D52103
llvm-svn: 342385
They're not that common, and falling back is definitely
better than throwing an error instead of the result. If we
feel motivated, we might end up implementing support for these,
but it's unclear whether it's worth the effort/complexity.
Fixes PR38925.
<rdar://problem/44436068>
llvm-svn: 342262
Summary:
This patch adds some symbol tag checks before using the `IPDBRawSymbol`
interface to improve safety and readability.
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51967
llvm-svn: 342208
I started from a clean slate to do the checkin, but forgot to svn add the new files.
Do that now.
Also add the one new source file to CMakeLists.txt
llvm-svn: 342190
This change allows you to write a new breakpoint type where the
logic for setting breakpoints is determined by a Python callback
written using the SB API's.
Differential Revision: https://reviews.llvm.org/D51830
llvm-svn: 342185
Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.
Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.
There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).
The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.
An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```
Reviewers: #lldb, jingham
Reviewed By: #lldb, jingham
Subscribers: jingham, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51175
llvm-svn: 342181
The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
different for other implementations.
llvm-svn: 342167
This patch improves the support of DWARF5.
Particularly the reporting of source code locations.
Differential revision: https://reviews.llvm.org/D51935
llvm-svn: 342153
After landing r341457, we started seeing a failure on the swift-lldb
bots. The change was correct and pretty straightforward, a DW_OP_constu
was replaced with DW_OP_lit23, the value remaining identical.
0x000000f4: DW_TAG_variable
DW_AT_location (0x00000000
[0x0000000100000a51, 0x0000000100000d47): DW_OP_lit23, DW_OP_stack_value)
DW_AT_name ("number")
However, this broke LLDB.
(Int) number = <extracting data from value failed>
The value was read correctly, but apparently the value's type was different.
When reading a constu it was reading a uint64 (m_type = e_ulonglong) while for
the literal, it got a signed int (m_type = e_sint). This change makes sure we
read the value as an unsigned.
Differential revision: https://reviews.llvm.org/D51730
llvm-svn: 342142
Summary:
Similar to what we did in D50681, we now stop manually byte counting here
in the SourceManager.
Reviewers: #lldb, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: JDevlieghere, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D50809
llvm-svn: 342121
Summary:
Building LLDB with xcodebuild sets the compatibility version of liblldb
in LLDB.framework. Building the framework with cmake does not set the
compatibility version, and so it defaults to 0.0.0. This is a discrepency in the
difference between the xcode build and the cmake build.
I tested this change by building without this patch. From the build tree I ran
`otool -L Library/Frameworks/LLDB.framework/Versions/A/LLDB` and got this:
```
@rpath/LLDB.framework/Versions/A/LLDB (compatibility version 0.0.0, current version 8.0.0)
```
Did the same with this patch and the output contained this:
```
@rpath/LLDB.framework/Versions/A/LLDB (compatibility version 1.0.0, current version 8.0.0)
```
Reviewers: clayborg, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D51959
llvm-svn: 342066
- gcc warning about using binary or for or-ing two comparisons (a == b | a == c)
- llvm style prefers static functions to functions in an anonymous namespace
llvm-svn: 342051
Summary:
One of the conclusions of the discussion on D49740 was that SafeMachO is better
off in the Host module (as that's the only place which should include
mach/machine.h, which is what this header is working around). Also, Utility,
which is the only module which cannot include Host, should not be doing
anything with object file formats.
This patch implements that move, and also removes any unneded includes of that
file.
I've verified that MacOS still compiles after this.
Reviewers: jingham, zturner, teemperor
Subscribers: fedor.sergeev, lldb-commits
Differential Revision: https://reviews.llvm.org/D50383
llvm-svn: 342050
Summary:
This patch removes the manual byte counting in all internal Stream methods.
This is now done by the automatic byte counting provided by calling `GetWrittenBytes()`
before and after writing the data (which is automatically done for us by the `ByteDelta`
utility class).
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50681
llvm-svn: 342044
The warning is about heap-allocating a struct with bigger alignment
requirements than the standard heap allocator provides.
AFAICT, all uses of the XSAVE struct are already heap-allocated, so this
high alignment does not actually have any effect and removing it should
be NFC.
I have also done some digging in the commit history. This alignment
requirement was since the XSAVE struct was introduced in r180572 when
adding AVX register support for linux. It does not mention the alignment
specifically, so I am guessing this was just put there because the
corresponging XSAVE cpu instruction requires its buffer to be 64-byte
aligned. However, LLDB will not be normally reading this struct via the
XSAVE instruction directly. Instead we will ask the kernel to copy the
buffer saved when suspeding the inferior. This should not require such
strict alignment (in fact, linux kernel will happily do this for any
alignment).
llvm-svn: 342029
Summary:
This commit fixes following problems after rL341782:
- Broken SymbolFilePDBTests
- Warning on comparison of integers of different signs
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341942
Summary:
The check is inverted here: If we have error messages, we should print those instead
of our default error message. But currently we print the default message when we
actually have a sensible error to print.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38383
Thanks Nat for the patch!
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51602
llvm-svn: 341940
Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form
Reviewers: jingham, #lldb
Reviewed By: jingham
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D51816
llvm-svn: 341849
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
This recommits r341487, which was reverted due to failing tests with
clang. It turned out I had incorrectly expected that the literal arrays
passed to ArrayRef constructor will have static (permanent) storage.
This was only the case with gcc, while clang was constructing them on
stack, leading to dangling pointers when the function returns.
The fix is to explicitly assign static storage duration to the opcode
arrays.
llvm-svn: 341758
Summary:
Previously we SetUseColor(true) wrongly when output was not a terminal so it broken some (not public) bots.
Thanks for issue report, @stella.stamenova
Reviewers: stella.stamenova, zturner
Reviewed By: stella.stamenova
Subscribers: abidh, lldb-commits, stella.stamenova
Differential Revision: https://reviews.llvm.org/D51772
llvm-svn: 341746
In a subsequent commit, I will need to expose the search depth
to the SB API's, so I'm moving this define into lldb-enumerations
where it will get added to the lldb module.
llvm-svn: 341690
This showed up in an Ubsan build of lldb (inside the CFAbsoluteTime
data formatter). As we only care about the bit pattern, we just
round to the nearest double, and truncate to a size that fits
in ulonglong_t.
<rdar://problem/44229924>
llvm-svn: 341682
code. This will enable disassembly of the optional subset of
neon that some Cortex cores support. Add a unit test to check
that a few of these instructions disassemble as expected.
<rdar://problem/26674303>
llvm-svn: 341623
The GetLanguageForExpr has side effects, so we can't remove this
call without breaking the completion mechanism. However, we can
keep the change that gets rid of this unnecessary variable.
llvm-svn: 341535
reads an ObjectFileMachO's string table in one chunk. Originally
this was commented out because binaries in the system's shared cache
all share a mega-string table and so reading the entire mega-strtab
for each binary was a performance problem.
In the reinstated code, I add a check that the binary we're reading
from memory is not in the shared cache (there isn't a constant in
<mach-o/loader.h> for this bit yet; we hardcode the value in one
other place in ObjectFileMachO alread). For binaries that we're
reading out of memory that are NOT in the shared cache, reading
the string table in one chunk is a big performance improvement.
Also have debugserver send up the flags value for binaries in its
response to the jGetLoadedDynamicLibrariesInfos request.
NFC.
<rdar://problem/33604496>
llvm-svn: 341511
This patch allows LLDB to print column info in backtraces et al. if
available, which is useful when the backtrace contains a frame like
the following:
f(can_crash(0), can_crash(1));
Differential Revision: https://reviews.llvm.org/D51661
llvm-svn: 341506
return the opcode as a Expected<ArrayRef> instead of a
Status+pointer+size combo.
I also move the linux implementation to the base class, as the trap
opcodes are likely to be the same for all/most implementations of the
class (except the arm one, where linux chooses a different opcode than
what the arm spec recommends, which I keep linux-specific).
llvm-svn: 341487
Summary:
LLVM provide (str)errno helpers, so convert code to use it.
Also fixes warning:
/home/xbolva00/LLVM/llvm/tools/lldb/source/Host/common/PseudoTerminal.cpp:248:25: warning: ignoring return value of ‘char* strerror_r(int, char*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
::strerror_r(errno, error_str, error_len);
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D51591
llvm-svn: 341320
If you tried to complete somwthing like ~/., lldb would come up with a lot
of non-existent filenames by concatenating every exisitng file in the directory
with an initial '.'.
This was due to a workaround for an llvm::fs::path::filename behavior that
was not applied selectively enough.
llvm-svn: 341268
Host info computation can involve DNS traffic (to compute the remote
host name). On very unreliable networks (such as free WiFi on trains),
this can take several seconds to complete or timeout. Increase the
qHostInfo timeout to account for this.
llvm-svn: 341164
The patch was originally written before we had a CompletionRequest,
so it still used a StringList to pass back the completions to
the request.
llvm-svn: 341124
Summary:
This class was initially in Host because its implementation used to be
very OS-specific. However, with C++11, it has become a very simple
std::condition_variable wrapper, with no host-specific code.
It is also a general purpose utility class, so it makes sense for it to
live in a place where it can be used by everyone.
This has no effect on the layering right now, but it enables me to later
move the Listener+Broadcaster+Event combo to a lower layer, which is
important, as these are used in a lot of places (notably for launching a
process in Host code).
Reviewers: jingham, zturner, teemperor
Reviewed By: zturner
Subscribers: xiaobai, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50384
llvm-svn: 341089
Summary:
This patch adds initial code completion support for the `expr` command.
We now have a completion handler in the expression CommandObject that
essentially just attempts to parse the given user expression with Clang with
an attached code completion consumer. We filter and prepare the
code completions provided by Clang and send them back to the completion
API.
The current completion is limited to variables that are in the current scope.
This includes local variables and all types used by local variables. We however
don't do any completion of symbols that are not used in the local scope (or
in some other way already in the ASTContext).
This is partly because there is not yet any code that manually searches for additiona
information in the debug information. Another cause is that for some reason the existing
code for loading these additional symbols when requested by Clang doesn't seem to work.
This will be fixed in a future patch.
Reviewers: jingham, teemperor
Reviewed By: teemperor
Subscribers: labath, aprantl, JDevlieghere, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48465
llvm-svn: 341086
This patch extends the SBAPI to allow for setting a breakpoint not
only at a specific line, but also at a specific (minimum) column. When
a column is specified, it will try to find an exact match or the
closest match on the same line that comes after the specified
location.
Differential Revision: https://reviews.llvm.org/D51461
llvm-svn: 341078
Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the line by underlining it via an ANSI color code.
Meaning that if you enable one, the other is automatically disabled by LLDB.
This was caused by the fact that both features inserted color codes into the the
source code and were likely to interfere with each other (which would result
in a broken source code printout to the user).
This patch moves the cursor code into the highlighting framework, which provides
the same feature to the user in normal non-C source code. For any source code
that is highlighted by Clang, we now also have cursor marking for the whole token
that is under the current source location. E.g., before we underlined only the '!' in the
expression '1 != 2', but now the whole token '!=' is underlined. The same for function
calls and so on. Below you can see two examples where we before only underlined
the first character of the token, but now underline the whole token.
{F7075400}
{F7075414}
It also simplifies the DisplaySourceLines method in the SourceManager as most of
the code in there was essentially just for getting this column marker to work as
a FormatEntity.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51466
llvm-svn: 341003
read/understand/maintain.
As a side-effect, this should also improve the performance by avoiding
costly vector element removals and switching from a std::map to a
SmallDenseSet.
Differential Revision: https://reviews.llvm.org/D51453
llvm-svn: 340994
Summary:
D48465 is currently blocked by the fact that tab-completing the first expression is deadlocking LLDB.
The reason for this deadlock is that when we push the ProcessIO handler for reading the Objective-C runtime
information from the executable (which is triggered when we parse the an expression for the first time),
the IOHandler can't be pushed as the Editline::Cancel method is deadlocking.
The deadlock in Editline is coming from the m_output_mutex, which is locked before we go into tab completion.
Even without this lock, calling Cancel on Editline will mean that Editline cleans up behind itself and deletes the
current user-input, which is screws up the console when we are tab-completing at the same time.
I think for now the most reasonable way of fixing this is to just not call Cancel on the current IOHandler when we push
the IOHandler for running an internal utility function.
As we can't really write unit tests for IOHandler itself (due to the hard dependency on an initialized Debugger including
all its global state) and Editline completion is currently also not really testable in an automatic fashion, the test for this has
to be that the expression command completion in D48465 doesn't fail when requesting completion the first time.
A more precise test plan for this is:
1. Apply D48465.
2. Start lldb and break in some function.
3. Type `expr foo` and press tab to request completion.
4. Without this patch, we deadlock and LLDB stops responding.
I'll provide an actual unit test for this once I got around and made the IOHandler code testable,
but for now unblocking D48465 is more critical.
Thanks to Jim for helping me debugging this.
Reviewers: jingham
Reviewed By: jingham
Subscribers: emaste, clayborg, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D50912
llvm-svn: 340988
The CvRecordPdb70 structure looks like:
struct CvRecordPdb70 {
uint8_t Uuid[16];
llvm::support::ulittle32_t Age;
// char PDBFileName[];
};
We were including the "Age" in the UUID for Apple vedors which caused us to not be able to match the UUID to built binaries. The "Age" field is set to zero in breakpad minidump files for Apple targets.
Differential Revision: https://reviews.llvm.org/D51442
llvm-svn: 340966
Summary:
This patch allows to resolve a symbol context block info even if a function
info was not requested. Also it adds the correct resolving of nested blocks
(the previous implementation used function blocks instead of them).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51104
llvm-svn: 340901
Summary:
For some bitfield patterns (like the one added by this commit), Clang will
generate non-regular data types like i24 or i48. This patch follows a
pretty naive approach of just bumping the type size to the next power of 2.
DataExtractor know how to deal with weird sizes. The operations on Scalar
do not know how to deal with those types though, so we have to legalize the
size when creating a Scalar.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51245
llvm-svn: 340880
Summary: limits.h is needed for getting PATH_MAX definition, this comes to fore
with musl libc where limits.h is not included indirectly via other system headers.
Patch by Khem Raj, thanks!
Reviewers: compnerd
Reviewed By: compnerd
Subscribers: llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31275
llvm-svn: 340876
Summary:
This patch replaces the manual lock/unlock calls for gaining exclusive access to the disassembler with
a RAII-powered access scope. This should prevent that we somehow skip over these trailing Unlock calls
(e.g. with early returns).
We also have a second `GetDisasmToUse` method now that takes an already constructed access scope to
prevent deadlocks when we call this from other methods.
Reviewers: #lldb, davide, vsk
Reviewed By: #lldb, davide, vsk
Subscribers: davide, vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D51319
llvm-svn: 340835
Summary:
Now that we moved the BuiltinContext and SelectorTable to the
CompilerInstance, we can also get rid of manually creating our
own ASTContext, but just use the one from the CompilerInstance
(which will be created with the same settings).
Reviewers: vsk, aprantl, davide
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51253
llvm-svn: 340748
Summary:
LLDB currently only checks the output terminal for color support by looking
at the `TERM` environment variable and comparing it to `"dumb"`. This causes that
when running LLDB on a CI node, the syntax highlighter will not be deactivated by
LLDB and the output log is filled with color codes (unless the terminal emulator
actually exposes itself as dumb).
This patch now relies on the LLVM code for detecting color support which is more
reliable. We now also correctly actually initialize the `m_supports_colors` variable in `File`.
`m_supports_colors` was so far uninitialized, but the code path that uses `m_supports_colors`
was also dead so the sanitizers didn't sound an alarm.
The old check that compares `TERM` is not removed by this patch as the new LLVM code
doesn't seem to handle this case (and it's a good thing to check for "dumb" terminals).
Reviewers: aprantl, javed.absar
Reviewed By: aprantl
Subscribers: kristof.beyls, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D51243
llvm-svn: 340747
Summary:
At the moment we create our own SelectorTable even though the Preprocessor always
creates one for us that we can (and should) reuse.
Reviewers: vsk
Reviewed By: vsk
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51185
llvm-svn: 340585
1. The dynamic loaders should not be needed for loading minidumps
and they may create problems (ex. the macOS loader resets the list of
loaded sections, which for minidumps are already set up during minidump loading)
2. In general, the extra plugins can do extraneous work which hurts performance
(ex. trying to set up implicit symbolic breakpoints, which in turn will trigger
extra debug information loading)
Differential Revision: https://reviews.llvm.org/D51176
llvm-svn: 340578
Summary:
Calling any non-libc builtin function in the expression command currently just causes Clang
to state that the function is not known. The reason for this is that we actually never
initialize the list of builtin functions in the Builtin::Context.
This patch just calls the initializer for the builtins in the preprocessor. Also adds some tests
for the new builtins.
It also gets rid of the extra list of builtins in the ClangExpressionParser, as we can just reuse
the existing list in the Preprocessor for the ASTContext. Having just one list of builtins around
is also closer to the standard Clang behavior.
Reviewers: #lldb, vsk
Reviewed By: vsk
Subscribers: sgraenitz, clayborg, vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D50481
llvm-svn: 340571
- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality
Patch by Shafik Yaghmour!
Differential Revision: https://reviews.llvm.org/D50864
llvm-svn: 340543
Summary:
Stream now has byte-counting functionality, so let's use this instead of manual byte
counting.
Reviewers: clayborg, davide
Reviewed By: davide
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D50677
llvm-svn: 340179
Summary:
.rela.debug_info relocations are being done via
ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case
that iterates over the relocation type is only implemented for a few
different types and `assert(false)`es over the rest.
Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations
Reviewers: sas, xiaobai, javed.absar, espindola
Reviewed By: sas
Subscribers: emaste, arichardson, kristof.beyls
Differential Revision: https://reviews.llvm.org/D50369
Change by Nathan Lanza <lanza@fb.com>
llvm-svn: 339974
These TODOs were for setting m_type in RegisterValue::SetValueFromString
in the case where reg_info's encoding was eEncodingUint or
eEncodingSint. m_type is set by SetUInt{8,16,32,64.128} during the
SetUInt call.
llvm-svn: 339959
when we have only an in-memory copy of the binary.
Also added a test for the generation of these symbols in the
in-memory and regular cases.
<rdar://problem/43160401>
llvm-svn: 339833
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
Summary:
This removes the manual byte counting mechanism from the syntax highlighting
code. This is no longer necessary as the Stream class now has built-in support for
automatically counting the bytes that were written to it so far.
The advantage of automatic byte counting via Stream is that it is less error-prone
than the manual version and we need to write less boilerplate code.
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50676
llvm-svn: 339695
Summary:
This issue came up because it caused problems in our unit tests. The StringPool did connect counterparts only once and silently ignored the values passed in subsequent calls.
The simplest solution for the unit tests would be silent overwrite. In practice, however, it seems useful to assert that we never overwrite a different mangled counterpart.
If we ever have mangled counterparts for other languages than C++, this makes it more likely to notice collisions.
I added an assertion that allows the following cases:
* inserting a new value
* overwriting the empty string
* overwriting with an identical value
I fixed the unit tests, which used "random" strings and thus produced collisions.
It would be even better if there was a way to reset or isolate the StringPool, but that's a different story.
Reviewers: jingham, friss, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50536
llvm-svn: 339669
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
Summary:
Removing FastDemangle will greatly reduce maintenance efforts. This patch replaces the last point of use in LLDB. Semantics should be kept intact.
Once this is agreed upon, we can:
* Remove the FastDemangle sources
* Add more features e.g. substitutions in template parameters, considering all variations, etc.
Depends on LLVM patch https://reviews.llvm.org/D50586
Reviewers: erik.pilkington, friss, jingham, JDevlieghere
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D50587
llvm-svn: 339583
Summary:
Instead of iterating over our vector of functions, we might as well use a map here to
directly get the function we need.
Thanks to Vedant for pointing this out.
Reviewers: vsk
Reviewed By: vsk
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D50225
llvm-svn: 339504
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
Profiling data show that Allocation::operator= is hot (see the data
attached to the Phab review).
Reorder a few fields within Allocation to avoid implicit structure
padding and shrink the structure. This should make copies a bit cheaper.
Also, given that an Allocation contains a std::vector (by way of
DataBufferHeap), it's preferable to make it move-only instead of
permitting expensive copies. As an added benefit this allows us to have
a single Allocation constructor instead of two.
Differential Revision: https://reviews.llvm.org/D50271
llvm-svn: 339290
clang doesn't use line number 0 (to mean artifically generated code) very often, but swift does it
quite often. We were rejecting all by line breakpoints in functions that started at line 0. But that's
a special marker so we can just not do this test in that case.
llvm-svn: 339182
Summary:
The new API appends an image search path to the
target's path mapping list.
Reviewers: aprantl, clayborg, labath
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D49739
llvm-svn: 339175
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching
2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf
symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
Summary:
.rela.debug_info relocations are being done via
ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case
that iterates over the relocation type is only implemented for a few
different types and `assert(false)`es over the rest.
Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations
Reviewers: sas, xiaobai, peter.smith, clayborg, javed.absar, espindola
Differential Revision: https://reviews.llvm.org/D49407
Change by Nathan Lanza <lanza@fb.com>
llvm-svn: 339068
In the lldb-bench/arithmetic benchmark, 1.7% of the total running time
is spent zero-initializing a std::vector that has already been zeroed.
llvm-svn: 339051
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
This is a fixed version of: https://reviews.llvm.org/D49750
The changes from D49750 are:
Don't init the m_arch in the Initialize call as a system info isn't required. This keeps the thread list, module list and other tests from failing
Added -Wextended-offsetof to Xcode project so we catch use extended usages of offsetof before submission
Fixed any extended offset of warnings
Differential Revision: https://reviews.llvm.org/D50336
llvm-svn: 339032
Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangled::GetDemangledName() was incorrect. What it actually wants is a check for null-string. Split this off of D50071 and added a test to clarify usage.
Reviewers: labath, jingham
Subscribers: erik.pilkington, lldb-commits
Differential Revision: https://reviews.llvm.org/D50327
llvm-svn: 339014
Summary:
We already have the same check directly before, so this code can never be
reached (as seen in the test coverage).
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50317
llvm-svn: 338976
I noticed a suspicious failure:
[ RUN ] VMRange.CollectionContains
llvm/src/tools/lldb/unittests/Utility/VMRangeTest.cpp:146: Failure
Value of: VMRange::ContainsRange(collection, VMRange(0x100, 0x104))
Actual: false
Expected: true
Looking at the code, it is a very real bug:
class RangeInRangeUnaryPredicate {
public:
RangeInRangeUnaryPredicate(VMRange range) : _range(range) {} // note that _range binds to a temporary!
bool operator()(const VMRange &range) const {
return range.Contains(_range);
}
const VMRange &_range;
};
This change fixes the bug.
Differential Revision: https://reviews.llvm.org/D50290
llvm-svn: 338949
Summary:
This wrapper will allow us in the future to reuse LLVM methods from within the
Stream class.
Currently no test as this is intended to be an internal class that shouldn't have any
NFC. The test for this change will be the follow up patch that migrates LLDB's
LEB128 implementation to the one from LLVM.
This change also adds custom move/assignment methods to Stream, as LLVM
raw_ostream doesn't support these. As our internal stream has anyway no state,
we can just keep the same stream object around.
Reviewers: davide, labath
Reviewed By: labath
Subscribers: xiaobai, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50161
llvm-svn: 338901
This reverts commit r338734 (and subsequent fixups in r338772 and
r338746), because it breaks some minidump unit tests and introduces a
lot of compiler warnings.
llvm-svn: 338828
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
Differential Revision: https://reviews.llvm.org/D49750
llvm-svn: 338734
Summary:
This patch allows LLDB's Stream class to count the bytes it has written to so far.
There are two major motivations for this patch:
The first one is that this will allow us to get rid of all the handwritten byte counting code
we have in LLDB so far. Examples for this are pretty much all functions in LLDB that
take a Stream to write to and return a size_t, which usually represents the bytes written.
By moving to this centralized byte counting mechanism, we hopefully can avoid some
tricky errors that happen when some code forgets to count the written bytes while
writing something to a stream.
The second motivation is that this is needed for the migration away from LLDB's `Stream`
and towards LLVM's `raw_ostream`. My current plan is to start offering a fake raw_ostream
class that just forwards to a LLDB Stream.
However, for this raw_ostream wrapper we need to fulfill the raw_ostream interface with
LLDB's Stream, which currently lacks the ability to count the bytes written so far (which
raw_ostream exposes by it's `tell()` method). By adding this functionality it is trivial to start
rolling out our raw_ostream wrapper (and then eventually completely move to raw_ostream).
Also, once this fake raw_ostream is available, we can start replacing our own code writing
to LLDB's Stream by LLVM code writing to raw_ostream. The best example for this is the
LEB128 encoding we currently ship, which can be replaced with by LLVM's version which
accepts an raw_ostream.
From the point of view of the pure source changes this test does, we essentially just renamed
the Write implementation in Stream to `WriteImpl` while the `Write` method everyone is using
to write its raw bytes is now just forwarding and counting the written bytes.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D50159
llvm-svn: 338733
Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANSI color escape sequences.
So far we have only one highlighter which is based on Clang and is responsible for all
languages that are supported by Clang. It essentially just runs the raw lexer over the input
and then surrounds the specific tokens with the configured escape sequences.
Reviewers: zturner, davide
Reviewed By: davide
Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D49334
llvm-svn: 338662
Summary:
When I added the Stream unit test (r338488), the build bots failed due to an out-of-
bound reads when passing an empty string to the PutCStringAsRawHex8 method.
In r338491 I removed the test case to fix the bots.
This patch fixes this in PutCStringAsRawHex8 by always checking for the terminating
null character in the given string (instead of skipping it the first time). It also re-adds the
test case I removed.
Reviewers: vsk
Reviewed By: vsk
Subscribers: vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D50149
llvm-svn: 338637
Summary:
Previously, I thought that install-liblldb would fail because CMake had
a bug related to installing frameworks. In actuality, I misunderstood the
semantics of `add_custom_target`: the DEPENDS option refers to specific files,
not targets. Therefore `install-liblldb` should rely on the actual liblldb
getting generated rather than the target.
This means that the previous patch I committed (to stop relying on CMake's
framework support) is no longer needed and has been reverted. Using CMake's
framework support greatly simplifies the implementation.
`install-lldb-framework` (and the stripped variant) is as simple as
depending on `install-liblldb` because CMake knows that liblldb was built as a
framework and will install the whole framework for you. The stripped variant
will depend on the stripped variants of individual tools only to ensure they
actually are stripped as well.
Reviewers: labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50038
llvm-svn: 338594
Clarify how StackFrameList works by documenting its methods. Also,
delete some dead code and insert some TODOs.
Differential Revision: https://reviews.llvm.org/D50087
llvm-svn: 338590
Splitting GetOnlyConcreteFramesUpTo will make it easier to implement
support for synthetic tail call frames in backtraces. This is just a
prep change, no functionality is affected.
llvm-svn: 338588
against the OS rather than the environment. Also update other
uses of OS when we meant environment in the android local code.
NFC intended.
llvm-svn: 338460
Summary: No one is using this method, and it also doesn't really make a lot of sense to have it around.
Reviewers: davide
Reviewed By: davide
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D50026
llvm-svn: 338345
Summary:
We usually don't have trailing newlines in the short help strings. This just adds
unnecessary extra lines when printing the help text of these commands.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50015
llvm-svn: 338311
This reverts r338154. This change is actually unnecessary, as the CMake
bug I referred to was actually not a bug but a misunderstanding of
CMake.
Original Differential Revision: https://reviews.llvm.org/D49888
llvm-svn: 338178
Summary: Stopgap patch to at least stop all the crashes I get from this code.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49949
llvm-svn: 338177
This broke a linux bot which doesn't support -std=c++17. The solution
is to add a decorator to skip these tests on machines with older compilers.
llvm-svn: 338162
This should have all the correct files now.
<rdar://problem/41471112>
Patch by Shafik Yaghmour.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 338156
Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:
Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.
Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.
This patch narrows the contract the CompletionRequest has with the different handlers to:
1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.
Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.
Otherwise this patch just completely hides the internal StringList to the different handlers.
The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.
Reviewers: jingham, davide, labath
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49322
llvm-svn: 338151
Summary:
So far lldb is printing this when it finds an ambiguous command:
```
(lldb) g
Ambiguous command 'g'. Possible matches:
gdb-remote
gui
gdb-remote
gui
```
The duplicates come from the fact that we call the same query twice with the same parameters
and add it to the same list. This patch just removes the second query call to `GetCommandObject`.
As `GetCommandObject` is const and the name parameter is also not modified, this shouldn't break
anything else. I didn't merge the remaining if statement into the else as I think otherwise the
`if obj==nullptr do X else Y` pattern in there becomes hard to recognize.
Reviewers: davide
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49866
llvm-svn: 338043
Summary:
We always print two error messages when we hit an unknown command. As the function
`CommandInterpreter::HandleCommand` that prints the second error message unconditionally called the `CommandInterpreter::ResolveCommandImpl` before (which prints the first error message), we can just remove
that second error message.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38312
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D49831
llvm-svn: 338040
Summary:
Replace the existing combination of FastDemangle and the fallback to llvm::itaniumDemangle() with LLVM's new ItaniumPartialDemangler. It slightly reduces complexity and slightly improves performance, but doesn't introduce conceptual changes. This patch is preparing for more fundamental improvements on LLDB's demangling approach.
Reviewers: friss, jingham, erik.pilkington, labath, clayborg, mgorny, davide, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: teemperor, JDevlieghere, labath, clayborg, davide, lldb-commits, mgorny, erik.pilkington
Differential Revision: https://reviews.llvm.org/D49612
llvm-svn: 337931
Summary: This class doesn't seem to be used anywhere, so we might as well remove the code.
Reviewers: labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49755
llvm-svn: 337855
Summary:
The dump function was the only part of this class which depended on
high-level functionality. This was due to the DumpDataExtractor
function, which uses info from a running target to control dump format
(although, RegisterValue doesn't really use the high-level part of
DumpDataExtractor).
This patch follows the same approach done for the DataExtractor class,
and extracts the dumping code into a separate function/file. This file
can stay in the higher level code, while the RegisterValue class and
anything that does not depend in dumping can stay go to lower layers.
The XCode project will need to be updated after this patch.
Reviewers: zturner, jingham, clayborg
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D48351
llvm-svn: 337832
Summary:
LLDB_PLUGINS doesn't exist as a variable, so this line doesn't add any dependencies and is
just confusing. It seems this slipped in from the gdb-remote CMake I was using as a CMake template.
The gdb-remote CMake itself is using a local LLDB_PLUGINS variable, so that code is fine.
Reviewers: davide
Reviewed By: davide
Subscribers: davide, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49695
llvm-svn: 337741
we were printing an extra space before the start for the expression and
an extra space after some dwarf operators. This makes sure we only print
exactly one space **between** operators and nowhere else.
llvm-svn: 337452
Summary: Right now we always try to retrieve ComSpec and if we fail, we give up. This rarely fails, but we can update the logic so that we fail even less frequently. Since there is a well-known path (albeit not always correct), try the path when we failed to retrieve it. Note that on other platforms, we generally just return a well-known path without any checking.
Reviewers: asmith, zturner, labath
Reviewed By: zturner, labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49451
llvm-svn: 337395
Summary:
Currently, if you build lldb-framework the entire framework doesn't
actually build. In order to build the entire framework, you need to actually
build lldb-suite. This abstraction doesn't feel quite right because
lldb-framework truly does depend on lldb-suite (liblldb + related tools).
In this change I want to invert their dependency. This will mean that lldb and
finish_swig will depend on lldb-framework in a framework build, and lldb-suite
otherwise. Instead of adding conditional logic everywhere to handle this, I
introduce LLDB_SUITE_TARGET to handle it.
Differential Revision: https://reviews.llvm.org/D49406
llvm-svn: 337311
We used to have a pretty stack trace printer in SystemInitializerCommon.
This was disabled on Apple because we didn't want the library to be
setting signal handlers, as this was causing issues when loaded into
Xcode. However, I think it's useful to have this for the LLDB driver, so
I moved it up to use the PrettyStackTraceProgram in the driver's main.
Differential revision: https://reviews.llvm.org/D49377
llvm-svn: 337261
The synthetic child providers for these classes had a type expression that matched
pointers & references to the type, but the Front End only worked on the actual object.
I fixed this by adding a way for the Synthetic Child FrontEnd provider to request dereference,
and then had these formatters use that mode.
<rdar://problem/40849836>
Differential Revision: https://reviews.llvm.org/D49279
llvm-svn: 337035
Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single CompletionRequest. In some cases we also pass an option
vector/index, but as we don't always have this information, it currently is not part of the
CompletionRequest class.
The constructor of the CompletionRequest is now also more sensible. You only pass the
user input, cursor position and your list of matches to the request and the rest will be
inferred (using the same code we used before to calculate this). You also have to pass these
match window parameters to it, even though they are unused right now.
The patch shouldn't change any behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48976
llvm-svn: 337031
Summary:
The refactoring patch for DoExecute missed this case of a variadic function that just silently
accepts a StringRef which it then tries to reinterpret as a C-string.
This should fix the Windows builds.
Reviewers: stella.stamenova
Reviewed By: stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49309
llvm-svn: 337030
The current version of SymbolFilePDB::ParseVariableForPDBData function
always initializes variables with an empty location. This patch adds the
converter of a location information from PDB to a DWARF expression, so
it becomes possible to watch values of variables of primitive data
types. At the moment the converter supports only Static, TLS, RegRel,
Enregistered and Constant PDB location types, but it seems that it's
enough for most cases. There are still some problems with retrieving
values of variables (e.g. we can't watch variables of composite types),
but they look not relevant to the conversion to DWARF.
Patch by: Aleksandr Urakov
Differential revision: https://reviews.llvm.org/D49018
llvm-svn: 336988
Summary:
This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function,
making the code simpler and less memory unsafe.
There seems to be a assumption in some command objects that this parameter could be a nullptr,
but from what I can see the rest of the API doesn't actually allow this (and other command
objects and related code pieces dereference this parameter without any checks).
Especially CommandObjectRegexCommand has error handling code for a nullptr that is now gone.
Reviewers: davide, jingham, teemperor
Reviewed By: teemperor
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D49207
llvm-svn: 336955
Corrupted minidumps was leading to unpredictable behavior.
This change adds explicit consistency checks for the minidump early on. The
checks are not comprehensive but they should catch obvious structural violations:
streams with type == 0
duplicate streams (same type)
overlapping streams
truncated minidumps
Another early check is to make sure we actually support the minidump architecture
instead of crashing at a random place deep inside LLDB.
Differential Revision: https://reviews.llvm.org/D49202
llvm-svn: 336918
Scalar::MakeUnsigned was implemented incorrectly so it didn't
really change the sign of the type (leaving signed types signed).
This showed up as a misevaluation when IR-interpreting urem but
it's likely to arise in other contexts.
This commit fixes the definition, and adds a test to make
sure this won't regress in future (hopefully).
Fixes rdar://problem/42038760 and LLVM PR38076
Differential Revision: https://reviews.llvm.org/D49155
llvm-svn: 336872
Summary: When ReadProcessMemory fails, bytes_read is sometimes set to a large garbage value. In that case, we need to set it back to zero before returning or the garbage value will be used to allocate memory later causing LLDB to crash with an out of memory error.
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner, asmith, stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D49159
llvm-svn: 336865
Summary:
This patch adds the possibility to specify an exit code when calling quit.
We accept any int, even though it depends on the user what happens if the int is
out of the range of what the operating system supports as exit codes.
Fixes rdar://problem/38452312
Reviewers: davide, jingham, clayborg
Reviewed By: jingham
Subscribers: clayborg, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48659
llvm-svn: 336824
Summary:
This patch splits out functionality from the `Parse` method into different methods.
This benefits the code completion work (which should reuse those methods) and makes the
code a bit more readable.
Note that this patch is as minimal as possible. Some of the code in the new methods definitely
needs more refactoring.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48339
llvm-svn: 336734
Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495
The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it.
Reviewers: asmith, zturner, aleksandr.urakov
Reviewed By: aleksandr.urakov
Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits
Differential Revision: https://reviews.llvm.org/D49111
llvm-svn: 336732
Summary:
A subset of the LLDB commands follows this command line interface style:
<command name> [arguments] -- <string suffix>
The parsing code for this interface has been so far been duplicated into the different
command objects which makes it hard to maintain and reuse elsewhere.
This patches improves the situation by adding a OptionsWithRaw class that centralizes
the parsing logic and allows easier testing. The different commands now just call this class to
extract the arguments and the raw suffix from the provided user input.
Reviewers: jingham
Reviewed By: jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49106
llvm-svn: 336723
This is the default in MacOS Mojave. No testcases, as basically
we have a lot of coverage (and the testsuite fails quite a bit
without this change in Beta 3).
Thanks to Fred Riss for helping me with this patch (fixing
bugs/nondeterminism).
<rdar://problem/38305553>
llvm-svn: 336607
Summary:
If we have an xvalue here, we will always hit the `err_typecheck_invalid_lvalue_addrof` error
in 'Sema::CheckAddressOfOperand' when trying to take the address of the result. This patch
uses the fallback code path where we store the result in a local variable instead when we hit
this case.
Fixes rdar://problem/40613277
Reviewers: jingham, vsk
Reviewed By: vsk
Subscribers: vsk, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48303
llvm-svn: 336582
Summary: The new API allows to find a list of compile units related to target/module.
Reviewers: aprantl, clayborg
Reviewed By: aprantl
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48801
llvm-svn: 336200
Summary:
1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case
2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues.
Reviewers: asmith, labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48844
llvm-svn: 336147
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
Summary:
The data structure is optimized for the case where the UUID size is <=
20 bytes (standard length emitted by the GNU linkers), but larger sizes
are also possible.
I've modified the string conversion function to support the new sizes as
well. For standard UUIDs it maintains the traditional formatting
(4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and
for longer UUIDs it will just repeat the last 6-byte block as long as
necessary.
I've also modified ObjectFileELF to take advantage of the new UUIDs and
avoid manually padding the UUID to 16 bytes. While there, I also made
sure the computed UUID does not depend on host endianness.
Reviewers: clayborg, lemo, sas, davide, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D48633
llvm-svn: 335963
The code was creating a StringRef to a temporary std::string. The
solution is to just drop the .str() from the original StringRef.
This manifested it self as the new TestCompletions test failing in some
configurations.
llvm-svn: 335960
This provides an efficient (at least on Posix platforms) way to offload to the
target process the search & loading of a library when all we have are the
library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
Summary:
To successfully open a core file, we need to have LLVM built with
support for the relevant target. Right now, if one does not have the
appropriate targets configured, the tests will fail.
This patch uses the GetBuildConfiguration SB API to inform the test (and
anyone else who cares) about the list of supported LLVM targets. The
test then uses this information to approriately skip the tests.
Reviewers: clayborg, jingham
Subscribers: martong, lldb-commits
Differential Revision: https://reviews.llvm.org/D48641
llvm-svn: 335859
Summary:
This patch fixes a problem with retrieving a function symbol by an
address in a nested block. In the current implementation of
ResolveSymbolContext function it retrieves a symbol with
PDB_SymType::None and then checks if found symbol's tag equals to
PDB_SymType::Function. So, if nested block's symbol was found,
ResolveSymbolContext does not resolve a function.
Reviewers: asmith, labath, zturner
Reviewed By: asmith, labath
Differential Revision: https://reviews.llvm.org/D47939
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>
llvm-svn: 335822
When running the test suite with .debug_names a bunch of tests were
failing because GetCompleteObjCClass was not yet implemented for
DebugNamesDWARFIndex. This patch adds the required logic.
We use the .debug_names to find the Objective-C class and then rely on
DW_AT_APPLE_objc_complete_type to find the complete type. If we can't
find it or the attribute is not supported, we return a list of potential
complete types.
Differential revision: https://reviews.llvm.org/D48596
llvm-svn: 335776
This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes.
llvm-svn: 335710
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
This method does one of two things:
1. finds a minimum os deployment version # in a Mach-O load
command and saves the three parts in the m_sdk_version, or
2. finds no valid min os version # load command, pushes a
sentinel value on the m_sdk_version vector so we don't search
the same load commands multiple times.
There was a little bug when we found a load command with
a version of 0.0.0 - the method would not add anything to
the m_sdk_version vector but would declare that a success.
It would not push the sentinel value to the vector.
There was code later in the method which assumed that
the vector always had a sentinel value, at least, and that
code could crash when this method was called back when
evaluating a Swift expression. (these version #'s are
fetched lazily so it wouldn't happen when the object file
was parsed, only when doing an expression that needed
the version #).
<rdar://problem/41372699>
llvm-svn: 335556
This reverts r335432 because remove_dots() is expensive and measuring
its impact showed an observable performance regression
(https://reviews.llvm.org/D45977#1078510).
llvm-svn: 335448
Removing redundant components from the path seems pretty harmless.
Rather than checking whether this is necessary and then actually doing
so, always invoke remove_dots to start with a normalized path.
llvm-svn: 335432
Replaces custom implementations of append and prepend with calls to
llvm's path library. This is part of a series of patches (started in
D48084) to delegate common operations to llvm::sys::path.
llvm-svn: 335430
Our DWARF parsing code had a workaorund for Objective-C "self" not
being marked as artifial by the compiler. Clang has been doing this
since 2010, so let's just drop the workaround.
llvm-svn: 335313
Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.
This reverts the #ifdef part of the above patch, while keeping the cmake
parts.
llvm-svn: 335260
I've made the code accept only 16 byte UUIDs, which is technically not
NFC (previously it would also accept 20 byte ones, but use only the
first 16 bytes), but this should be more correct as mac UUIDs are always
16 byte long.
llvm-svn: 335247
Instead of a separate GetBytes + GetByteSize methods I introduce a
single GetBytes method returning an ArrayRef.
This is NFC cleanup now, but it should make handling arbitrarily-sized
UUIDs cleaner, should we choose to go that way. I also took the
opportunity to add some unit tests for this class.
llvm-svn: 335244
Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linking of the Python plugin in liblldb. This
plugin is already included as a part of LLDB_ALL_PLUGINS variable.
llvm-svn: 335236
Sign-extension of small types (e.g. short) was not handled correctly.
The reason for that was that when we were assigning the a value to the
Scalar object, we would accidentally promote the type to int (even
though the assignment code in AssignTypeToMatch tried to cast the value
to the appropriate type, it would still invoke the "int" version of
operator=). Instead, I use the APInt version of operator=, where the
bitwidth is specified explicitly. Among other things, this allows us to
fold the individual size cases into one.
llvm-svn: 335114
Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47384 did for clang, by
moving the path computation into the python plugin and modifying
SBHostOS class to call into this module for ePathTypePythonDir.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D48215
llvm-svn: 335104
passes to the recursive search function so we only recursively
search the kext bundle directory, instead of its parent directory.
<rdar://problem/41227170>
Differential Revision: https://reviews.llvm.org/D48302
llvm-svn: 335079
Summary:
OnExit ensures we call `ResetDeclMap` before this method ends. However,
we also have a few manual calls to ResetDeclMap in there that are actually unnecessary
because of this (calling the method multiple times has no effect). This patch also moves
the class out of the method that we can reuse it for the upcoming method that handles
parsing for completion.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48337
llvm-svn: 335078
StringConvert was the only non-Utility dependency of this class. Getting
rid of it means it will be easy to move this class to a lower layer.
While I was in there, I also added a couple of unit tests for the Scalar
string conversion function.
llvm-svn: 335060
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of functions, each returning a single path
kind. This makes it easy to move the python-path function into a
specific plugin in a follow-up commit.
All the users of GetLLDBPath were converted to call specific functions
instead. Most of them were hard-coding the enum value anyway, so this
conversion was simple. The only exception was SBHostOS, which I've
changed to use a switch on the incoming enum value.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48272
llvm-svn: 335052
DynamicLoaderDarwinKernel plugin. Created a new function ReadMachHeader
and instead of reading through the target cached memory reader,
start by reading only a mach header sized chunk of memory, then
check it for a valid mach-o magic # and use the size of the load
commands to pre-fetch the entire load commands of the kext which
is the only thing we're going to read, instead of letting the generic
mach-o parser read it in 512 byte chunks.
Functionally this is doing exactly the same thing as before, but by
cutting down on the # of packets going back and forth, even on a
local connection it's close to a quarter faster than it was before.
<rdar://problem/38570146>
llvm-svn: 334995
We didn't add the remaining path behind the '~' to the completion string,
causing it to just complete directories inside the user home directory. This
patch just adds the directory of the remaining path if there is one.
Fixes rdar://problem/40147002
llvm-svn: 334978
Summary:
In this patch I aim to do the following:
1) Create an lldb-framework target that acts as the target that handles generating LLDB.framework. Previously, liblldb acted as the target for generating the framework in addition to generating the actual lldb library. This made the target feel overloaded.
2) Centralize framework generation as much as it makes sense to do so.
3) Create a target lldb-suite, which depends on every tool and library that makes liblldb fully functional. One result of having this target is it makes tracking dependencies much clearer.
Differential Revision: https://reviews.llvm.org/D48060
llvm-svn: 334968
I actually did check that macos builds before committing, but this error
was in conditionally compiled code that did not seem to be used on my
machine.
I also fix a typo in the previous speculative NetBSD patch.
llvm-svn: 334955
Summary:
This has multiple advantages:
- we need only one function argument/instance variable instead of three
- no need to default initialize variables
- no custom parsing code
- VersionTuple has comparison operators, which makes version comparisons much
simpler
Reviewers: zturner, friss, clayborg, jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D47889
llvm-svn: 334950
George Rimar
