If users call "static void lldb::SBDebugger::Terminate()" we will clean up the debugger list, and users can individually destroy debugger instances with "static void lldb::SBDebugger::Destroy(SBDebugger &)". But if we let the C++ destructor chain tear down this list, other threads that might still be running as the main thread exits can now crash if they access the debugger list. We stop this by leaking the debugger list and its mutex.
<rdar://problem/26372169>
llvm-svn: 270869
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
We don't want a mutex in debugger as it will cause A/B locking issues with the lldb_private::Target's mutex, but we do need to stop two threads from doing Debugger::Clear at the same time. We have seen issues with this with the C++ global destructor chain where the global debugger list is being destroyed and the Debugger::~Debugger() is calling it while another thread was in the middle of running that function.
<rdar://problem/26098913>
llvm-svn: 268563
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
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
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
Summary:
With the recent changes to separate clang from the core structures
of LLDB, many inclusions of clang headers can be removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12954
llvm-svn: 248004
debugging optimized code. Adds new methods on Function/SBFunction
to query whether a given function is optimized. Adds a new
function.is-optimized format entity and changes the default
frame-format to append "[opt]" if the function was built with
optimization.
The only indication that a binary was built with optimization
that we have right now is the presence of the DW_AT_APPLE_optimized
attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit.
The absence of this flag may mean that the compile_unit was not
compiled with optimization, or it may mean that the producer
does not generate this attribute.
Currently this only works for dSYM debugging. When we create
the CompileUnit with dwarf-in-.o-file debugging we don't have
the attribute value yet so it's not set. I need to find the
flag value when we do start to read the .o file DWARF and
set the CompileUnit's status at that point - but haven't
done it yet.
I'm also going to add a mechanism for issuing warnings to users
such that they're only issued once in a debug session and
there is away for users to suppress these warnings altogether
via .lldbinit file settings. But I want to get this changeset
committed now that it's at a useful state.
<rdar://problem/19281172>
llvm-svn: 243508
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
This change also get rid of an unused Debugger instance in
GDBRemoteCommunicationServerLLGS and the command interpreter from
lldb-platform what was used only for enabling logging.
Differential revision: http://reviews.llvm.org/D9876
llvm-svn: 238319
Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
(different) Greg's patch, but I have added stronger synchronization to it to avoid races.
Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.
Test Plan: Prompt comes out alright. All tests still pass on linux.
Reviewers: clayborg, emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9823
llvm-svn: 238313
Summary:
Previously the Debugger::HandleProcessEvent hid a top IOHandler if the
process's IOHandler was inactive and later refreshed it. Usually the
IOHandler.Refresh() prints the (lldb) prompt. The problem was in case of
iOS remote platform when trying to execute 'command source' command.
On this platform the process's IOHandler is empty, therefore the
Debugger::HandleProcessEvent hid a top IOHandler and later refreshed it.
So that the (lldb) prompt was printed with a program output in mixed
order:
was:
```
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglonglonglonglonglonglonglon(lldb)
glonglonglonglonglonglonglonglonglonglonglonglong string
```
now:
```
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglong string
```
Reviewers: zturner, jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, jingham, zturner, clayborg
Differential Revision: http://reviews.llvm.org/D8929
llvm-svn: 234517
In an effort to reduce binary size for components not wishing to
link against all of LLDB, as well as a parallel effort to reduce
link dependencies on Python, this patch splits out the notion of
LLDB initialization into "full" and "common" initialization.
All code related to initializing the full LLDB suite lives directly
in API now. Previously it was only referenced from API, but because
it was defined in lldbCore, it would get implicitly linked against
by everything including lldb-server, causing a considerable
increase in binary size.
By moving this to the API layer, it also creates a better layering
for the ongoing effort to make the embedded interpreter replacable
with one from a different language (or even be completely removeable).
One semantic change necessary to get this all working was to remove
the notion of a shared debugger refcount. The debugger is either
initialized or uninitialized now, and calling Initialize() multiple
times will simply have no effect, while the first Terminate() will
now shut it down no matter how many times Initialize() was called.
This behaves nicely with all of our supported usage patterns though,
and allows us to fix a number of nasty hacks from before.
Differential Revision: http://reviews.llvm.org/D8462
llvm-svn: 233758
Summary:
Presently, if a log file already exists, lldb simply starts overwriting bits of it, without
truncating or anything. This patch makes it use eFileOptionFileTruncate by default. It also adds
an --append option, which will append to the file without truncating. A test is included.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8450
llvm-svn: 232801
This creates a new top-level folder called Initialization which
is intended to hold code specific to LLDB system initialization.
Currently this holds the Initialize() and Terminate() functions,
as well as the fatal error handler.
This provides a means to break the massive dependency cycle which
is caused by the fact that Debugger depends on Initialize and
Terminate which then depends on the entire LLDB project. With
this structure, it will be possible for applications to invoke
lldb_private::Initialize() directly, and have that invoke
Debugger::Initialize.
llvm-svn: 232768
Greg Clayton
Saleem Abdulrasool
Kate Stone
Jim Ingham
Eugene Zelenko
Mohit K. Bhakkad
Sean Callanan
Siva Chandra
Bruce Mitchener
Oleksiy Vyalov
Jason Molenda
Zachary Turner
Tamas Berghammer
Pavel Labath
Ilia K