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
In the process of hoisting the LoadScriptingResourceForModule
out of Target::ModuleAdded and into Target::ModulesDidLoad,
I had ModulesDidLoad fetching the Target's entire image list
and look for scripting resources in those -- instead of only
looking for scripting resources in the modules that had
been added to the target's image list.
<rdar://problem/50065315>
llvm-svn: 358929
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:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.
What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.
I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).
With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.
What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.
Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille
Reviewed By: aprantl
Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D58125
llvm-svn: 355939
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
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
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
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
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
Summary:
The target was being used in FinalizeFileActions to provide default
values for stdin/out/err. Also, most of the logic of this function was
very specific to how the lldb's Target class wants to launch processes,
so I, move it to Target::FinalizeFileActions, inverting the dependency.
The only piece of logic that was useful elsewhere (lldb-server) was the
part which sets up a pty and relevant file actions. I've kept this part
as ProcessLaunchInfo::SetUpPtyRedirection.
This makes ProcessLaunchInfo independent of any high-level lldb constructs.
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56196
llvm-svn: 350617
Summary:
The Debuffer object was being used in "GetListenerForProcess" to provide
a default listener object if one was not specified in the launch_info
object.
Since all the callers of this function immediately passed the result to
Target::CreateProcess, it was easy to move this logic there instead.
This brings us one step closer towards being able to move the LaunchInfo
classes to the Host layer (which is there the launching code that
consumes them lives).
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56174
llvm-svn: 350510
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
We need to ensure that Finalize gets called before we start
to destroy the old Process or the weak_ptr->shared_ptr link
from Threads to Target gets broken before the threads are
destroyed.
<rdar://problem/43586979>
Differential Revision: https://reviews.llvm.org/D55631
llvm-svn: 349435
Summary:
These are general purpose "utility" classes, whose functionality is not
debugger-specific in any way. As such, I believe they belong in the
Utility module.
This doesn't break any particular dependency (yet), but it reduces the
number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
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
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
qWatchpointSupportInfo packet correctly.
In GDBRemoteCommunicationClient::GetWatchpointSupportInfo,
if the response to qWatchpointSupportInfo does not
include the 'num' field, then we did not get an answer
we understood, mark this target as not supporting that
packet.
In Target.cpp, rename the very confusingly named
CheckIfWatchpointsExhausted to CheckIfWatchpointsSupported,
and check the error status returned by
Process::GetWatchpointSupportInfo. If we cannot determine
what the number of supported watchpoints are, assume that
they will work. We'll handle the failure
later when we try to create/enable the watchpoint if the
Z2 packet isn't supported.
Add a gdb_remote_client test case.
<rdar://problem/42621432>
llvm-svn: 346561
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
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 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
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
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
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
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
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
PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those.
Changes include:
Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason.
Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info
Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code.
Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other.
Added tests for absolute, relative and empty paths.
Differential Revision: https://reviews.llvm.org/D47021
llvm-svn: 332842
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
This allows us to collect useful metrics about lldb debugging sessions.
I thought that an example would be better than a thousand words:
Process 19705 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100000fb4 blah`main at blah.c:3
1 int main(void) {
2 int a = 6;
-> 3 return 0;
4 }
(lldb) statistics enable
(lldb) frame var a
(int) a = 6
(lldb) expr a
(int) $1 = 6
(lldb) statistics disable
(lldb) statistics dump
Number of expr evaluation successes : 1
Number of expr evaluation failures : 0
Number of frame var successes : 1
Number of frame var failures : 0
Future improvements might include:
1. Passing a file, or implementing categories. The way this patch has
been implemented is generic enough to allow this to be extended
easily without breaking the grammar.
2. Adding an SBAPI and Python API for use in scripts.
Thanks to Jim Ingham for discussing the design with me.
<rdar://problem/36555975>
Differential Revision: https://reviews.llvm.org/D45547
llvm-svn: 330043
When using:
(lldb) settings set target.source-map ./ /path/to/source
LLDB would fail to set a source file and line breakpoint with:
(lldb) breakpoint set --file /path/to/source/main.c --line 2
Because code in the target was undoing the remapping of "/path/to/source/main.c" to "./main.c" and then it would resolve this path, which would append the current working directory to the path. We don't want to resolve paths that we unmap.
Test case added.
Differential Revision: https://reviews.llvm.org/D44502
llvm-svn: 327600
It turns out that setting the clang module cache after LLDB has a
Target can be too late. In particular, the Swift language plugin needs
to know the setting without having access to a Target. This patch
moves the setting into the *LLDB* module cache, where it is a global
setting that is available before any Target is created and more
importantly, is shared between all Targets.
rdar://problem/37944432
Differential Revision: https://reviews.llvm.org/D43984
llvm-svn: 326628
This patch makes LLDB's clang module cache path customizable via
settings set target.clang-modules-cache-path <path> and uses it in the
LLDB testsuite to reuse the same location inside the build directory
for LLDB and clang.
Differential Revision: https://reviews.llvm.org/D43099
llvm-svn: 324775
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
I was warning about the fact that this will abort
further stop hooks, but didn't check that there WAS
a further stop hook. Also the warning was missing a
newline.
llvm-svn: 319730
This creates a new Architecture plugin and moves the stop info override
callback to this place. The motivation for this is to remove complex
dependencies from the ArchSpec class because it is used in a lot of
places that (should) know nothing about Process instances and StopInfo
objects.
I also add a test for the functionality covered by the override
callback.
Differential Revision: https://reviews.llvm.org/D31172
llvm-svn: 316609
This setting can be enabled like this at the target level:
(lldb) settings set target.experimental.use-modern-type-lookup true
This causes several new behaviors in the Clang expression parser:
- It completely disables use of ClangASTImporter. None are created
at all, and all users of it are now conditionalized on its
presence.
- It instead constructs a per-expression ExternalASTMerger, which
exists inside Clang and contains much of the type completion
logic that hitherto lived in ExternalASTSource,
ClangExpressionDeclMap, and ClangASTImporter.
- The expression parser uses this Merger as a backend for copying
and completing types.
- It also constructs a persistent ExternalASTMerger which is
connected to the Target's persistent AST context.
This is a major chunk of LLDB functionality moved into Clang. It
can be tested in two ways:
1. For an individual debug session, enable the setting before
running a target.
2. For the testsuite, change the option to be default-true. This
is done in Target.cpp's g_experimental_properties. The
testsuite is not yet clean with this, so I have not committed
that switch.
I have filed a Bugzilla for extending the testsuite to allow
custom settings for all tests:
https://bugs.llvm.org/show_bug.cgi?id=34771
I have also filed a Bugzilla for fixing the remaining testsuite
failures with this setting enabled:
https://bugs.llvm.org/show_bug.cgi?id=34772
llvm-svn: 314458
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
Summary:
It defined a couple of types (condition_t) which we don't use anymore,
as we have c++11 goodies now. I remove these definitions.
Also it unnecessarily included a couple of headers which weren't
necessary for it's operation. I remove these, and place the includes in
the relevant files (usually .cpp, usually in Host code) which use them.
This allows us to reduce namespace pollution in most of the lldb files
which don't need the OS-specific definitions.
Reviewers: zturner, jingham
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D35113
llvm-svn: 308304
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Loading a shared library can require a large amount of work; rather than do that serially for each library,
this patch will allow parallelization of the symbols and debug info name indexes.
From scott.smith@purestorage.comhttps://reviews.llvm.org/D32598
llvm-svn: 301609
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
This adds formatv-backed formatting functions in various
places in LLDB such as StreamString, logging, constructing
error messages, etc. A couple of callsites are changed
from Printf style syntax to formatv style syntax to
illustrate its usage. Additionally, a FileSpec formatter
is introduced so that FileSpecs can be formatted natively.
Differential Revision: https://reviews.llvm.org/D27632
llvm-svn: 289922
This changes most of the class to use the new Timeout class. The one function
left is RunThreadPlan, which I left for a separate change as the function is
massive. A couple of things to call out:
- I've renamed the affected functions to match the listener interface names. This
should also help catch any places I did not convert at compile time.
- I've deleted the WaitForState function as it was unused.
llvm-svn: 288241
This was a bit tricky, especially for things like
OptionValueArray and OptionValueDictionary since they do some
funky string parsing. Rather than try to re-write line-by-line
I tried to make the StringRef usage idiomatic, even though
it meant often re-writing from scratch large blocks of code
in a different way while keeping true to the original intent.
The finished code is a big improvement though, and often much
shorter than the original code. All tests and unit tests
pass on Windows and Linux.
llvm-svn: 287242
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
Summary:
"Initialization of function-local statics is guaranteed to occur only once even when called from
multiple threads, and may be more efficient than the equivalent code using std::call_once."
<http://en.cppreference.com/w/cpp/thread/call_once>
I'd add that it's also more readable.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17710
llvm-svn: 284601
This allows debugging of the JIT and other analyses of the internals of the
expression parser. I've also added a testcase that verifies that the setting
works correctly when off and on.
llvm-svn: 282434
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way in the first place.) Added an SBBreakpointList class
so there's a way to specify which breakpoints to serialize and to report the
deserialized breakpoints.
<rdar://problem/12611863>
llvm-svn: 281520
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
This feature was added to solve a lookup problem in expressions when local variables
shadow ivars. That solution requires fully realizing all local variables to evaluate
any expression, and can cause significant performance problems when evaluating
expressions in frames that have many complex locals.
Until we get a better solution, this setting mitigates the problem when you don't
have local variables that shadow ivars.
<rdar://problem/27226122>
llvm-svn: 274783
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
within a source file.
This isn't done, I need to make the name match smarter (right now it requires an
exact match which is annoying for methods of a class in a namespace.
Also, though we use it in tests all over the place, it doesn't look like we have
a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch.
llvm-svn: 267834
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
LLDB can remap a source file to a new directory based on the
"target.sorce-map" to handle the usecase when the source code moved
between the compliation and the debugging. Previously the remapping
was only used to display the content of the file. This CL fixes the
scenario when a breakpoint is set based on the new an absolute path
with adding an inverse remapping step before looking up the breakpoint
location.
Differential revision: http://reviews.llvm.org/D17848
llvm-svn: 262711
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
The Calculate* functions in general should not derive any information that isn't
implicit, but for Target the process pointer is a member so it's fine to return
it for CalculateProcess().
llvm-svn: 260713
SUMMARY:
Get the load address for the address given by symbol and function.
Earlier, this was done for function only, this patch does it for symbol too.
This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change.
Reviewers: clayborg
Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16049
llvm-svn: 258919
If your program refers to modules (as indicated in DWARF) we will now try to
load these modules and give you access to their types in expressions. This used
to be gated by a setting ("settings set target.auto-import-clang-modules true")
but that setting defaulted to false. Now it defaults to true -- but you can
disable it by toggling the setting to false.
llvm-svn: 257812
breakpoint as "file address" so that the address breakpoint will track that
module even if it gets loaded in a different place. Also fixed the Address
breakpoint resolver so that it handles this tracking correctly.
llvm-svn: 253308
It used to be a unique pointer, and there could be a case where ClangASTSource
held onto a copy of the pointer but Target::Destroy destroyed the unique pointer
in the mean time.
I also ensured that there is a validity check on the target (which confirms that
a ClangASTImporter can be generated) before the target's shared pointer is
copied into ClangASTSource.
This race condition caused a crash if Target::Destroy was called and then later
the target objecct was deleted.
llvm-svn: 252665
"Modify internal breakpoints so they resolve just like external
breakpoints do. This allow you to set symbol and file + line internal
breakpoints and have them get updated correctly."
<rdar://problem/16931767>
llvm-svn: 252584
triple for a process. He writes, "Changes to the way setting the
triple works on a target so that if the target has passed a fully
specified triple, and the newly passed triple is not a revamp of
the current one, and the current one is fully specified, then do
not replace the existing triple."
Triple handling got a bit more complicated on mac with the addition
of ios/watchos/tvos and their simulators, and tracking the correct
os versions for them so expressions are compiled with the expected
APIs available to the user.
<rdar://problem/19820698>
llvm-svn: 252583
instance:
break set -l c++ -r Name
will only break on C++ symbols that match Name, not ObjC or plain C symbols. This also works
for "break set -n" and there are SB API's to pass this as well.
llvm-svn: 252356
StackFrame * (StackFrame is an ExecutionContextScope.) That allows you to call an
expression on a particular Thread, but not using the context of any particular frame.
That in turn is useful for injecting utility functions that don't actually depend on
locals/self/etc of the current frame.
I also had to include StackFrame.h in a couple of places so the compiler knew
how to downcast StackFrame to ExecutionContextScope.
<rdar://problem/22852953>
llvm-svn: 251564
Before, in the absence of any configured REPLs, LLDB would act as if there were
multiple possible REPL options, whereas actually no REPL language is supported.
Now we make a better error.
llvm-svn: 250931
To allow that, I've added a SetREPL call to the Target, which allows a REPL
that just created a target to install itself as the go-to REPL for the
corresponding language.
llvm-svn: 250870
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion. The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.
Also added a PluginManager-based way of getting to a REPL given a language and
a target.
Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.
llvm-svn: 250753
Instead check what languages are supported for expressions; use C if available,
but otherwise pick one of the supported languages.
This can be overridden using the target settings.
<rdar://problem/22290878>
llvm-svn: 249864
This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases.
llvm-svn: 249747
Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo.
<rdar://problem/22821480>
llvm-svn: 249361
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Both GNU AS and LLVM emits language type DW_LANG_Mips_Assembler for
all assembly code.
Differential revision: http://reviews.llvm.org/D12962
llvm-svn: 248146
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
SUMMARY:
This patch implements Target::GetBreakableLoadAddress() method that takes an address
and checks for any reason there is a better address than this to put a breakpoint on.
If there is then return that address.
MIPS uses this method to avoid breakpoint in delay slot.
Reviewers: clayborg, jingham
Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits
Differential Revision: http://http://reviews.llvm.org/D12184
llvm-svn: 246015
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat.
Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit().
Now we aren't leaking file descriptors and the stand alone test suite should run much better.
llvm-svn: 238089
This patch initially was committed in r237460 but later it was reverted (r237479) due to 4 new failures:
* TestExitDuringStep.py
* TestNumThreads.py
* TestThreadExit.py
* TestThreadStates.py
This patch also fixes these tests.
llvm-svn: 237566
Summary:
This option forces to only set a source line breakpoint when there is an exact-match
This patch includes the following commits:
# Add the -m/--exact-match option in "breakpoint set" command
## Add exact_match arg in BreakpointResolverFileLine ctor
## Add m_exact_match field in BreakpointResolverFileLine
## Add exact_match arg in BreakpointResolverFileRegex ctor
## Add m_exact_match field in BreakpointResolverFileRegex
## Add exact_match arg in Target::CreateSourceRegexBreakpoint
## Add exact_match arg in Target::CreateBreakpoint
## Add -m/--exact-match option in "breakpoint set" command
# Add target.exact-match option to skip BP if source line doesn't match
## Add target.exact-match global option
## Add Target::GetExactMatch
## Refactor Target::CreateSourceRegexBreakpoint to accept LazyBool exact_match (was bool)
## Refactor Target::CreateBreakpoint to accept LazyBool exact_match (was bool)
# Add target.exact-match test in SettingsCommandTestCase
# Add BreakpointOptionsTestCase tests to test --skip-prologue/--exact-match options
# Fix a few typos in lldbutil.check_breakpoint_result func
# Rename --exact-match/m_exact_match/exact_match/GetExactMatch to --move-to-nearest-code/m_move_to_nearest_code/move_to_nearest_code/GetMoveToNearestCode
# Add exact_match field in BreakpointResolverFileLine::GetDescription and BreakpointResolverFileRegex::GetDescription, for example:
was:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
now:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
Test Plan:
./dotest.py -v --executable $BUILDDIR/bin/lldb functionalities/breakpoint/
./dotest.py -v --executable $BUILDDIR/bin/lldb settings/
./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/breakpoint/
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9273
llvm-svn: 237460
Summary:
This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.
Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.
Handling of '%' async notification packets will be added next.
Reviewers: clayborg
Subscribers: lldb-commits, ADodds, ted, deepak2427
Differential Revision: http://reviews.llvm.org/D9656
llvm-svn: 237239
Summary: This patch moves synchronization of iohandler to CommandObjectProcessLaunch::DoExecute like it was done in CommandObjectProcessContinue::DoExecute.
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9373
llvm-svn: 236699
breakpoints, for instance on the class of the thrown object.
This change doesn't actually make that work, the part where we
extract the thrown object type from the throw site isn't done yet.
This provides a general programmatic "precondition" that you can add
to breakpoints to give them the ability to do filtering on the LLDB
side before we pass the stop on to the user-provided conditions &
callbacks.
llvm-svn: 235538
module-loading support for the expression parser.
- It adds support for auto-loading modules referred
to by a compile unit. These references are
currently in the form of empty translation units.
This functionality is gated by the setting
target.auto-import-clang-modules (boolean) = false
- It improves and corrects support for loading
macros from modules, currently by textually
pasting all #defines into the user's expression.
The improvements center around including only those
modules that are relevant to the current context -
hand-loaded modules and the modules that are imported
from the current compile unit.
- It adds an "opt-in" mechanism for all of this
functionality. Modules have to be explicitly
imported (via @import) or auto-loaded (by enabling
the above setting) to enable any of this
functionality.
It also adds support to the compile unit and symbol
file code to deal with empty translation units that
indicate module imports, and plumbs this through to
the CompileUnit interface.
Finally, it makes the following changes to the test
suite:
- It adds a testcase that verifies that modules are
automatically loaded when the appropriate setting
is enabled (lang/objc/modules-auto-import); and
- It modifies lanb/objc/modules-incomplete to test
the case where a module #undefs something that is
#defined in another module.
<rdar://problem/20299554>
llvm-svn: 235313
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
virtual void
LanguageRuntime::ModulesDidLoad (const ModuleList &module_list);
Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses.
llvm-svn: 235118
verifying that the types from that module don't
override types from DWARF. Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.
<rdar://problem/18805055>
llvm-svn: 234016
When no hijack listener is set up, the global event listener will
try to pull events off the queue, racing with the event thread.
By always forcing a hijack listener, even when one was not given,
we guarantee that the listener always gets all events.
This was causing problems in synchronous mode with the process
stop event sometimes never being picked up and causing the debugger
to hang while processing a .lldbinit file.
Reviewed by: Jim Ingham
Differential Revision: http://reviews.llvm.org/D8562
llvm-svn: 233315
Previously the remote module sepcification was fetched only from the
remote platform. With this CL if we have a remote process then we ask it
if it have any information from a given module. It is required because
on android the dynamic linker only reports the name of the SO file and
the platform can't always find it without a full path (the process can
do it based on /proc/<pid>/maps).
Differential revision: http://reviews.llvm.org/D8547
llvm-svn: 233061
Summary:
Saw this while reading some code in DynamicLoader classes. Looks like this has
been a FIXME since 2011 at least.
Test Plan: Run unit tests.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8558
llvm-svn: 232983
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
Previously it was fetched only if the architecture isn't valid, but the
architecture can be valid without containing all information about the
current target (e.g. missing os).
Differential revision: http://reviews.llvm.org/D8057
llvm-svn: 232153
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
Summary:
This patch adds -exec-arguments command for lldb-mi. -exec-arguments command allows to specify arguments for executable file in MI mode. Also it contains tests for that command.
Btw, new added files was formatted by clang-format.
Reviewers: abidh, zturner, clayborg
Reviewed By: clayborg
Subscribers: zturner, emaste, clayborg, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D6965
llvm-svn: 229110
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
Because types are not reliably protected against the death of their owners, having ValueObjects lurking around like that past the useful lifetime of their owner processes is a potential source of crashes
That is - in itself - worth fixing at some point, but for this case, watchpoints holding on to old values don't offer enough value to make the larger fix worth
Fixes rdar://19788756
llvm-svn: 228777
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
New functions to give client applications to tools to discover target byte sizes
for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the
SBTarget class, since they seemed to be useful utilities to have.
Each new API has had a test case added.
http://reviews.llvm.org/D5867
llvm-svn: 220372
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.
Several log lines have been added around PTY and stdout/stderr redirection
logic on the lldb client side.
Regarding remote llgs execution, see the following:
With these changes, remote llgs with $O now works properly:
$ lldb
(lldb) platform select remote-linux
(lldb) target create ~/some/inferior/exe
(lldb) gdb-remote {some-target}:{port}
(lldb) run
The sequence above will correctly redirect stdout/stderr over gdb-remote $O,
as is needed for remote debugging. That sequence assumes there is a lldb-gdbserver
exe running on the target with {some-host}:{port}.
You can replace the gdb-remote command with a '(lldb) platform connect
connect://{target-ip}:{target-port}'. If you do this and have a
lldb-platform running on the remote end, it will go ahead and launch
llgs for lldb for each target instance that is run/attached.
For local debugging with llgs, the following sequence also works, and
uses local PTYs instead to avoid $O and extra gdb-remote messages:
$ lldb
(lldb) settings set platform.plugin.linux.use-llgs true
(lldb) target create ~/some/inferior/exe
(lldb) run
The above will run the inferior using llgs on the local host, and
will use PTYs rather than $O redirection.
This change also removes the logging that happened after the fork but
before the exec when llgs is launching a new inferior process. Some
aspect of the file handling during that portion of code would not do
the right thing with log handling. We might want to go back later
and have that communicate over a pipe from the child to parent to pass
along any messages that previously were logged in that section of code.
llvm-svn: 219578
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553
This setting contains the following:
A list containing all the arguments to be passed to the expression parser compiler.
This change also ensures quoted arguments are handled appropriately.
See http://reviews.llvm.org/D5472 for more details.
Change by Tong Shen.
llvm-svn: 219169
See thread started here for motivation:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-September/005225.html
This change enables the ability to set breakpoints in ccache-based and executables that
make use of preprocessed source files. This ability existed in lldb before, but was off
by default.
Change by Doug Snyder.
llvm-svn: 218405
lldb's internal memory cache chunks that are read from the remote
system. For a remote connection that is especially slow, a user may
need to reduce it; reading a 512 byte chunk of memory whenever a
4-byte region is requested may not be the right decision in these
kinds of environments.
<rdar://problem/18175117>
llvm-svn: 217083
GCC emits a warning:
warning: enumeral and non-enumeral type in conditional expression [enabled by default]
which does not seem to have a flag to control it. Simply add an explicit cast
for the boolean value.
llvm-svn: 213715
This change enables lldb-platform for Linux. In addition, it does the following:
* fixes Host::GetLLDBPath() to work on Linux/*BSD for ePathTypeSupportExecutableDir-relative paths.
* adds more logging and comments around lldb-platform startup and remote lldb-platform usage.
* refactors lldb-platform remote-* support for Darwin and Linux into PlatformPOSIX. This, in theory, is the bulk of what is needed for *BSD to make remote connections to lldb-platform as well (although I haven't tested that yet). FreeBSD can make similar changes to their Platform* as was made here for PlatformLinux to pick up the rest of the bits.
* teaches GDBRemoteCommunication to use lldb-gdbserver for non-Apple hosts.
llvm-svn: 213707
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
Frederic Riss