Beside turning the options into the new tablegen format, this patch
also fixes that a few commands had source file completions for the
"count" and "end-linenumber" arguments (which both accepted only
integers). Reason for that are that somehow we added a '1' instead
of our usual '0' value to the initial value for completion.
llvm-svn: 366425
It seems having two Options.inc files in the same project is giving our
custom Xcode project a hard time. This patch renames the new Options.inc
to CommandOptions.inc to prevent this conflict.
llvm-svn: 366196
Summary: This patch adds documentation that should make it easier to migrate from using the old initializers to the table gen format.
Reviewers: jingham
Reviewed By: jingham
Subscribers: abidh, lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64670
llvm-svn: 366083
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
Summary:
PersistentStateExpressions (e.g. ClangPersistentVariables) have the
ability to define types using expressions that persist throughout the
debugging session. GetCompilerTypeFromPersistentDecl is a useful
operation to have if you need to use any of those persistently declared types,
like in CommandObjectMemory.
This decouples clang from CommandObjectMemory and decouples Plugins from
Commands in general.
Differential Revision: https://reviews.llvm.org/D62797
llvm-svn: 363183
Summary:
Previous patch (r360409) introduced the "symbol file unwind plan"
concept, but that plan wasn't used for unwinding yet. With this patch,
we start to consider the new plan as a possible strategy for both
synchronous and asynchronous unwinding. I also add a test that asserts
that unwinding via breakpad STACK CFI info works end-to-end.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits, amccarth, markmentovai
Differential Revision: https://reviews.llvm.org/D61853
llvm-svn: 361618
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Before this change we were overriding the launch info environment with
the target environment. This meant that the environment variables passed
to `process launch --environment <>` were lost. Instead of replacing the
environment, we should merge them.
Differential revision: https://reviews.llvm.org/D61864
llvm-svn: 360612
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
This patch ensures that we propagate errors coming from the lldbinit
file trough the command/script interpreter. Before, if you did something
like command script import syntax_error.py, and the python file
contained a syntax error, lldb wouldn't tell you about it. This changes
with the current patch: errors are now propagated by default.
PS: Jim authored this change and I added testing.
Differential revision: https://reviews.llvm.org/D61579
llvm-svn: 360216
You can only find out about this useful customization by browsing
the settings list output or the llvm.org web pages. Mention it
in the help for thread list, thread backtrace & _regex_bt commands
to make it more discoverable.
llvm-svn: 359752
This patch ensures that we honor the stop-command-source-on-error
setting from `command source`. The problem is that we didn't
differentiate between the boolean value being true or false, or not
being set. For the latter scenario, we should calculate the value in the
command interpreter based on the global options.
Differential revision: https://reviews.llvm.org/D61406
llvm-svn: 359750
In r359354 a GetDebugger() method was added to the CommandObject class,
so that we didn't have to go through the command interpreter to obtain
the script interpreter. This patch simplifies other call sites where
m_interpreter.GetDebugger() was used, and replaces them with a shorter
call to the new method.
llvm-svn: 359373
This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
the debugger. I would've preferred to remove the lazy initialization,
however the fact that the scripting language is set after the debugger
is created makes that tricky. So for now this does exactly the same
thing as when it was under the command interpreter. The result is that
this patch is fully NFC.
Differential revision: https://reviews.llvm.org/D61211
llvm-svn: 359354
Before a Debugger gets a Target, target settings are routed to a global set
of settings. Even without this, some part of the LLDB which exist independently
of the Debugger object (the Module cache, the Symbol vendors, ...) access
directly the global default store for those settings.
Of course, if you modify one of those global settings while they are being read,
bad things happen. We see this quite a bit with FileSpecList settings. In
particular, we see many cases where one debug session changes
target.exec-search-paths while another session starts up and it crashes when
one of those accesses invalid FileSpecs.
This patch addresses the specific FileSpecList issue by adding locking to
OptionValueFileSpecList and never returning by reference.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60468
llvm-svn: 359028
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
Add a flag to control whether the ModulesDidLoad notification is
called when a module is added. If the notifications are disabled,
the caller must call ModulesDidLoad after adding all the new modules,
but postponing this notification until they're all batched up can
allow for better efficiency than notifying one-by-one.
Change the name of the ModuleList notifier functions that a subclass
can implement to start with 'Notify' to make it clear what they are.
Add a NotifyModulesRemoved.
Add header documentation for the changed/updated methods.
Added defaulted-value 'notify' argument to ModuleList Append,
AppendIfNeeded, and Remove because callers working with a local
ModuleList don't have an obvious idea of what notify means in this
context. When the ModuleList is a part of the Target class, the
notify behavior matters.
DynamicLoaderDarwin has been updated so that libraries being
added/removed are correctly batched up before notifications are
sent. Added the TestModuleLoadedNotifys.py test to run on
Darwin to test this.
<rdar://problem/48293064>
Differential Revision: https://reviews.llvm.org/D60172
llvm-svn: 357955
Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.
For example:
command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...
I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.
However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.
Reviewers: clayborg, jingham
Reviewed By: clayborg
Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits
Differential Revision: https://reviews.llvm.org/D48752
llvm-svn: 355793
Inspired by Zachary's mail on lldb-dev, this seemed like low hanging
fruit. This patch breaks the circular dependency between commands and
expression.
Differential revision: https://reviews.llvm.org/D59158
llvm-svn: 355762
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
This patch adds the necessary logic to capture and replay commands
entered into the command interpreter. A DataRecorder shadows the input
and writes its data to a know file. During replay this file is used as
the command interpreter's input.
It's possible to the command interpreter more than once, with a
different input source. We support this scenario by using multiple
buffers. The synchronization for this takes place at the SB layer, where
we create a new recorder every time the debugger input is changed.
During replay we use the corresponding buffer as input.
Differential revision: https://reviews.llvm.org/D58564
llvm-svn: 355249
When the debugger is run in sync mode, you need to
be able to tell whether a hijacked resume is for some
special purpose (like waiting for the SIGSTOP on attach)
or just to perform a synchronous resume. Target::Launch was doing
that wrong, and that caused stop-hooks on process launch
in source files to behave incorrectly.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58727
llvm-svn: 355213
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
They aren't designed to nest recursively, so this will prevent that.
Also add a --auto-continue flag, putting "continue" in the stop hook makes
the stop hooks fight one another in multi-threaded programs.
Also allow more than one -o options so you can make more complex stop hooks w/o
having to go into the editor.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58394
llvm-svn: 354706
Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
Reviewers: jasonmolenda, clayborg, espindola
Subscribers: lemo, emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D58129
llvm-svn: 354033
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This reapplies r350802, which was reverted because of issues with
parsing posix-style paths on windows hosts (and vice-versa). These have
since been fixed in r351328, and lldb should now recognise the path
style used in a dwarf compile unit correctly.
llvm-svn: 351435
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.
To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.
rdar://problem/47178964
Differential Revision: https://reviews.llvm.org/D56688
llvm-svn: 351214
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.
llvm-svn: 351133
This reverts commit r350802 because the test fails on windows. This
happens because we treat the paths as windows paths even though they
have linux path separators in the asm file. That results in wrong paths
being computed (\tmp\tmp\a.c instead of /tmp/a.c).
Reverting until I can figure out what to do with this.
llvm-svn: 350810
Summary:
The motivation for this is being able to write tests for the upcoming
breakpad line table parser, but this could be useful for testing the
low-level workings of any line table format. Or simply for viewing the
line table information with more detail (the brief format doesn't
include any of the flags for end_of_prologue and similar).
I've also removed the load_addresses argument from the
DumpCompileUnitLineTable function, as it wasn't being used anywhere.
Reviewers: clayborg, zturner
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56315
llvm-svn: 350802
LLVM added wrappers to std::sort (r327219) that randomly shuffle the
container before sorting. The goal is to uncover non-determinism due to
undefined sorting order of objects having the same key.
This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON.
llvm-svn: 350679
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
Summary:
This function was named such because in the case of MachO files, the
mach header is located at this address. However all (most?) usages of
this function were not interested in that fact, but the fact that this
address is used as the base address for expressing various relative
addresses in the object file.
For other object file formats, this name is not appropriate (and it's
probably the reason why this function was not implemented in these
classes). In the ELF case the ELF header will usually end up at this
address, but this is a result of the linker optimizing the file layout
and not a requirement of the spec. For COFF files, I believe the is no
header located at this address either.
Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55422
llvm-svn: 348849
Summary: Instead use a more reasonable value to start and rely on the fact that SmallString will resize if necessary.
Reviewers: labath, asmith
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55457
llvm-svn: 348775
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
This adds new APIs and a command to deal with exceptions (mostly Obj-C exceptions): SBThread and Thread get GetCurrentException API, which returns an SBValue/ValueObjectSP with the current exception for a thread. "Current" means an exception that is currently being thrown, caught or otherwise processed. In this patch, we only know about the exception when in objc_exception_throw, but subsequent patches will expand this (and add GetCurrentExceptionBacktrace, which will return an SBThread/ThreadSP containing a historical thread backtrace retrieved from the exception object. Currently unimplemented, subsequent patches will implement this).
Extracting the exception from objc_exception_throw is implemented by adding a frame recognizer.
This also add a new sub-command "thread exception", which prints the current exception.
Differential Revision: https://reviews.llvm.org/D43886
llvm-svn: 347813
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
After committing the initial reproducer feature I noticed a few small
issues which warranted addressing here. It fixes incorrect documentation
in the command object and extract some duplicated code into the debugger
object.
llvm-svn: 346919
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.
Differential revision: https://reviews.llvm.org/D54272
llvm-svn: 346598
The whole point of this change was making it possible to resolve paths
without depending on the FileSystem, which is not what I did here. Not
sure what I was thinking...
llvm-svn: 346466
In order to call real_path from the TildeExpressionResolver we need
access to the FileSystem. Since the resolver lives under utility we have
to pass in the FS.
llvm-svn: 346457
This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info. It can also be used to write tests
against.
Differential Revision: https://reviews.llvm.org/D54072
llvm-svn: 346149
This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.
Differential revision: https://reviews.llvm.org/D54020
llvm-svn: 346049
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53831
llvm-svn: 345843
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
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
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
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
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
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
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
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
Alex Langford