Checking in the support for doing index ids reservation when given a thread id.

llvm-svn: 171904

Python OS plug-ins now fetch thread registers lazily.

Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".

llvm-svn: 171901

llvm-svn: 171900

llvm-svn: 171869

llvm-svn: 171864

- Fixes test case TestConnectRemote

llvm-svn: 171855

Implement -w flag to process launch (allow launching inferior process in different working directory) on Linux/FreeBSD
- fixes test case TestProcessLaunch

llvm-svn: 171854

Ensuring that the Module's FileSpec is not NULL before attempting to deref it for loading the python scripting resource

llvm-svn: 171838

Fix TestSendSignals.py on Linux. The wrong stop reason was being set when stopping for a received signal.

llvm-svn: 171819

Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file.

Also fixed issues in the test suite that arose after fixing the bug.

Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option.

llvm-svn: 171816

llvm-svn: 171810

- bug fixed in r170241, thanks Andy!
- closing related PR 14423

llvm-svn: 171794

Add unconditional logging messages to every place in debugserver
where we send a SIGKILL signal or do a ptrace PT_KILL call to
terminate the inferior process.  When the debuggee is silently
killed off, the console logging from debugserver can disambiguate
whether debugserver killed off the process because it failed to
completely set it up, becuase it was told to (via the "k" packet),
or if some external daemon killed it.

llvm-svn: 171606

- due to bugzilla 14806 (platform status command prints more information on Mac OS X than on Linux)

llvm-svn: 171569

- setting PYTHONPATH is no longer needed to run the lldb CLI on Linux.
- added instructions for setting PYTHONPATH correctly for running scripts in the native interpreter

llvm-svn: 171566

Have the disassembler's Instruction::Dump always insert at least
one space character between an opcode and its arguments, don't let
a long opcode name abut the arguments.

llvm-svn: 171561

- now prints the correct PYTHONPATH
- update dotest.py to use lldb -P result correctly
- resolves TestPublicAPIHeaders test failure (on Linux)

llvm-svn: 171558

llvm-svn: 171554

instead of failing to read.

<rdar://problem/12958589>

llvm-svn: 171552

llvm-svn: 171548

- requires memory allocation during expression evaluation
- opened related bugzilla 14805

llvm-svn: 171547

llvm-svn: 171542

llvm-svn: 171500

Added a page that describes how to to manual symbolication with LLDB from the command line, from python, and also how to use the build in modules to do symbolication.

llvm-svn: 171477

Added SBTarget::EvaluateExpression() so expressions can be evaluated without needing a process.

Also fixed many functions that deal with clang AST types to be able to properly handle the clang::Type::Elaborated types ("struct foo", "class bar").

llvm-svn: 171476

for id types with protocols on them.  We detect this
and report "id" instead.

Also added a testcase.

<rdar://problem/12595644>

llvm-svn: 171431

llvm-svn: 171381

migration in r171366.

I don't know anything about lldb, but a force run of the build bot indicated it
would need this patch. I'll try to watch the build bot to get it green.

llvm-svn: 171374

llvm-svn: 170975

the IR interpreter.

<rdar://problem/12921700>

llvm-svn: 170934

Added an SBAPI to get the PythonPath (if the Host knows how to do that).  And a -P option to the Driver
to print it out.  Changed dotest.py to use that to find the PythonPath it should use given the lldb binary
it was told to run.

llvm-svn: 170932

The results from Clang name lookups changed to
be ArrayRefs, so I had to change the way we
check for the presence of a result and the way
we iterate across results.

llvm-svn: 170927

slice of a fat dSYM in certain cases.

<rdar://problem/12921206>

llvm-svn: 170926

Not all of the expected instructions were being generated for the function being disassembled on x86-64-based Linux.  It had no push, pop or leave.

llvm-svn: 170818

llvm-svn: 170800

If we can't find the python function for a given summary, print the name of the function in the warning message.

llvm-svn: 170729

a bit.

llvm-svn: 170641

When looking for the Python script to load for a given module, replace dots with underscores if there are any after stripping the extension
This means that for a module named foo.devel.xyz a file named foo_devel.py will be what we try to load

llvm-svn: 170633

Note that the test actually fails before reaching the assertion described in that bug, but the failure is a trivial matter of adding OS-conditional expected stop reason strings (as noted by new comments in this patch).  However, with the stop reason strings changed, the test fails for the more substantial reason noted in bugzilla 14662.

llvm-svn: 170619

Implement the ability for Python commands to be interrupted by pressing CTRL+C
Also add a new Mutex subclass that attempts to be helpful for debugging by logging actions performed on it

FYI of all interested - there is a separate deadlocking issue related to how LLDB dispatches CTRL+C that might cause LLDB to deadlock upon pressing CTRL+C while in a Python command.
This is not a regression, and was just previously masked by us not even trying to bail out of Python commands, so that it would not be clear from a user perspective whether we were
deadlocked or stuck in an inconsistent state within the Python interpreter.

llvm-svn: 170612