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
After http://reviews.llvm.org/D8133 landed as r231550 process launch on remote platform stopped working.
This adds Debugger::InitializeForLLGS and tracks whether one or both of Initialize and InitializeForLLGS have been called, calling only the corresponding lldb_private::Terminate* methods as necessary. Since lldb_private::Terminate calls lldb_private::TerminateForLLGS, the latter method may be called twice if Initialize was called for both however the terminate methods ensure they are only called once after being initialized.
This still maintains the reduced binary size, though it does now technically link in lldb_private::Terminate on lldb-server even though this should never be called.
This should resolve the issue raised in http://reviews.llvm.org/D8133 where Debugger::Terminate assumed that there were 0 references to debugger and terminated early.
Differential Revision: http://reviews.llvm.org/D8183
llvm-svn: 231808
changing it was in r219544 - after living on that for a few
months, I wanted to take another crack at this.
The disassembly-format setting still exists and the old format
can be user specified with a setting like
${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}:
This patch was discussed in http://reviews.llvm.org/D7578
<rdar://problem/19726421>
llvm-svn: 229186
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning.
The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably.
Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands.
<rdar://problem/17751929>
<rdar://problem/16953815>
<rdar://problem/16953841>
<rdar://problem/16930173>
<rdar://problem/16879028>
llvm-svn: 226068
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
format for the not-current-stack-frame. This was causing
test/functionalities/inferior-assert to fail.
Also document the new additions to the format specifications used
in the disassembly-format changes to formats.html.
<rdar://problem/19102757>
llvm-svn: 223096
% lldb /bin/nonono
(lldb) target create "/bin/nonono"
error: unable to find executable for '/usr/bin/nonono'
<deadlock>
The problem was the initial commands 'target create "/bin/nonono"' were put into a pipe and the command interpreter was being run with:
void
CommandInterpreter::RunCommandInterpreter(bool auto_handle_events,
bool spawn_thread,
CommandInterpreterRunOptions &options)
{
// Always re-create the command intepreter when we run it in case
// any file handles have changed.
bool force_create = true;
m_debugger.PushIOHandler(GetIOHandler(force_create, &options));
m_stopped_for_crash = false;
if (auto_handle_events)
m_debugger.StartEventHandlerThread();
if (spawn_thread)
{
m_debugger.StartIOHandlerThread();
}
else
{
m_debugger.ExecuteIOHanders();
if (auto_handle_events)
m_debugger.StopEventHandlerThread();
}
}
If "auto_handle_events" was set to true and "spawn_thread" was false, we would execute:
m_debugger.StartEventHandlerThread();
m_debugger.ExecuteIOHanders();
m_debugger.StopEventHandlerThread();
The problem was there was no synchonization in Debugger::StartEventHandlerThread() to ensure the event handler was listening to events and the the call to "m_debugger.StopEventHandlerThread()" would do:
void
Debugger::StopEventHandlerThread()
{
if (m_event_handler_thread.IsJoinable())
{
GetCommandInterpreter().BroadcastEvent(CommandInterpreter::eBroadcastBitQuitCommandReceived);
m_event_handler_thread.Join(nullptr);
}
}
The problem was that the event thread might not be listening for the CommandInterpreter::eBroadcastBitQuitCommandReceived event yet.
The solution is to make sure the Debugger::DefaultEventHandler() is listening to events before we return from Debugger::StartEventHandlerThread(). Once we have this synchonization we remove the race condition.
This fixes radar:
<rdar://problem/19041192>
llvm-svn: 223083
(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
I went back and forth on removing this - and tried dropping it for
a few weeks. But when you're working at an assembly language, it
really is helpful to have this displayed to show where the current
pc is.
llvm-svn: 221682
The recent StringPrinter changes made this behavior the default, and the setting defaults to yes
If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false
Fixes rdar://12969594
llvm-svn: 221399
better output when we don't have any symbol name.
It looked like this:
0x1097fd029 <ud2
0x1097fd02b <addb %al, (%rax)
now, like this:
0x10cdd3064: ud2
0x10cdd3066: addb %al, (%rax)
<rdar://problem/18833391>
llvm-svn: 220948
This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is
${var.script:someFuncName}
someFuncName is expected to be declared as
def someFuncName(SBValue,otherArgument) - essentially the same as a summary function
Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous
llvm-svn: 220821
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
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548
llvm-svn: 219143
Saleem Abdulrasool