LLDB help content has accumulated over time without a recent attempt to
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text rela

LLDB help content has accumulated over time without a recent attempt to
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.

<rdar://problem/24868841>

llvm-svn: 275485

show more ...

second pass over removal of Mutex and Condition

llvm-svn: 270024

Fix deadlock due to thread list locking in 'bt all' with obj-c

Summary:
The gdb-remote async thread cannot modify thread state while the main thread
holds a lock on the state. Don't use locking thre

Fix deadlock due to thread list locking in 'bt all' with obj-c

Summary:
The gdb-remote async thread cannot modify thread state while the main thread
holds a lock on the state. Don't use locking thread iteration for bt all.

Specifically, the deadlock manifests when lldb attempts to JIT code to
symbolicate objective c while backtracing. As part of this code path,
SetPrivateState() is called on an async thread. This async thread will
block waiting for the thread_list lock held by the main thread in
CommandObjectIterateOverThreads. The main thread will also block on the
async thread during DoResume (although with a timeout), leading to a
deadlock. Due to the timeout, the deadlock is not immediately apparent,
but the inferior will be left in an invalid state after the bt all completes,
and objective-c symbols will not be successfully resolved in the backtrace.

Reviewers: andrew.w.kaylor, jingham, clayborg

Subscribers: sas, lldb-commits

Differential Revision: http://reviews.llvm.org/D18075

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 263735

show more ...

This change introduces a "ExpressionExecutionThread" to the ThreadList.

Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was

This change introduces a "ExpressionExecutionThread" to the ThreadList.

Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.

I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.

<rdar://problem/24978569>

llvm-svn: 263326

show more ...

Add the "block" keyword to "thread step-in -e", and an alias that uses it: "sif <target function>" - i.e. step-into-function
to allow you to step through a complex calling sequence into a particular

Add the "block" keyword to "thread step-in -e", and an alias that uses it: "sif <target function>" - i.e. step-into-function
to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some
test cases for this and the --step-target feature.

llvm-svn: 261953

show more ...

Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in source/Commands/CommandObjectThread.cpp; other minor fixes.

llvm-svn: 261936

Adding an SBThread::StepInto that takes an end-line, also moved the code that figures
out the address range for the step to SymbolContext.

llvm-svn: 260772

This is an idea to make "thread step-in --target" work for the common
case where you have:

1 -> foo (bar(),
2 baz(),
3 lala());
4

You are sitting on line 1, and want to ste

This is an idea to make "thread step-in --target" work for the common
case where you have:

1 -> foo (bar(),
2 baz(),
3 lala());
4

You are sitting on line 1, and want to step into foo, but not bar, baz & lala. Unfortunately
there are line table entries for lines 1-3, and lldb doesn't know anything about the nesting
of statement in these lines. So we'll have to use the user's intelligence... This patch adds:

(lldb) thread step-in -t foo --end-line 4

That tells lldb to keep stepping in till line 4, but stop if you step into foo. I think I would
remember to use this when faced with some of the long gnarly call sequences in lldb. But there
might be ways I haven't thought of to make it more convenient. Jason suggests having "end" as a
special token for --end-line which just means keep going to the end of the function, I really want
to get into this thing...

There should be an SB API and tests, which will come if this seems useful.

llvm-svn: 260352

show more ...

Fix "thread backtrace -s": option was misparsed because of a missing break.

<rdar://problem/24525106>

llvm-svn: 259962

When constructing an address range to "step" or "next" through,
find the largest address range (possibly combining multiple
LineEntry's for this line number) that is contiguous.

This allows lldb's

When constructing an address range to "step" or "next" through,
find the largest address range (possibly combining multiple
LineEntry's for this line number) that is contiguous.

This allows lldb's fast-step stepping algorithm to potentially
run for a longer address range than if we have to stop at every
LineEntry indicating a subexpression in the source line.

http://reviews.llvm.org/D15407
<rdar://problem/23270882>

llvm-svn: 255590

show more ...

commands: Use override instead of virtual.

Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.

It also adds override where virtual was pre

commands: Use override instead of virtual.

Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.

It also adds override where virtual was previously
missing.

Reviewers: clayborg, labath

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D13503

llvm-svn: 249564

show more ...

Don't #include "lldb-python.h" from anywhere.

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,

Don't #include "lldb-python.h" from anywhere.

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

show more ...

Improve LLDB prompt handling

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 introduc

Improve LLDB prompt handling

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

show more ...

Add support for custom commands to set flags on themselves
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::Ge

Add support for custom commands to set flags on themselves
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())

Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones

llvm-svn: 238286

show more ...

Remote Non-Stop Support

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

Remote Non-Stop Support

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

show more ...

Add an assertion for frame[0] being valid in CommandObjectThread.cpp.

Summary:
This should always be true but sometimes is not, during platform bring
up. As recommended by Jim Ingham, an assertion s

Add an assertion for frame[0] being valid in CommandObjectThread.cpp.

Summary:
This should always be true but sometimes is not, during platform bring
up. As recommended by Jim Ingham, an assertion should be enough here to
help.
This addresses post commit comments in http://reviews.llvm.org/D8554.

Test Plan: Run unit tests.

Reviewers: jasonmolenda, emaste, jingham, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D8574

llvm-svn: 233298

show more ...

Add a missing null pointer check in CommandObjectThread.cpp.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D8554

llvm-svn: 232979

Don't #include FormatManager.h from Debugger.h

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

Don't #include FormatManager.h from Debugger.h

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

show more ...

Add a "-a/--address" option to "thread until". You can specify one or more line numbers (as arguments)
and/or one or more addresses (with -a) and until will stop at the first one of thesepoints it

Add a "-a/--address" option to "thread until". You can specify one or more line numbers (as arguments)
and/or one or more addresses (with -a) and until will stop at the first one of thesepoints it hits,
or on exit from the function if you leave the function before hitting any of these stop points.

<rdar://problem/12438270>

llvm-svn: 228370

show more ...

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused fun

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb

llvm-svn: 226199

show more ...

Change int32_t to uint32_t to fix warnings.

Variable was being declared as signed, but treated as unsigned at
every point of use.

Patch by Dan Sinclair
Differential Revision: http://reviews.llvm.or

Change int32_t to uint32_t to fix warnings.

Variable was being declared as signed, but treated as unsigned at
every point of use.

Patch by Dan Sinclair
Differential Revision: http://reviews.llvm.org/D6897

llvm-svn: 225540

show more ...

Make the "synchronous" mode actually work without race conditions.

There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condit

Make the "synchronous" mode actually work without race conditions.

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

show more ...

LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction

Reviewed at http://reviews.llvm.org/D5592

This patch gives LLDB some ability to interact with Add

LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction

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

show more ...

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and t

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.

I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.

llvm-svn: 218642

show more ...

Fix iohandler prompt race condition.

This issue caused the lldb prompt to not show up in certain cases, very
noticeable on Linux systems.

See details on this review:
http://reviews.llvm.org/D4863

Fix iohandler prompt race condition.

This issue caused the lldb prompt to not show up in certain cases, very
noticeable on Linux systems.

See details on this review:
http://reviews.llvm.org/D4863

And on this lldb-commits thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html

Change by Shawn Best.

(Much useful help and testing by the rest of the community, thanks all!)

llvm-svn: 215446

show more ...