Update assertion in DYLDRendezvous.

This accounts for the case where a dlopen() call fails when loading a library with a missing dependency.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219520 91177308-0d34-0410-b5e6-96231b3b80d8
When parsing ObjC types from encoded strings (and disallowing any-type), the ^? combination gets resolved to no type, while we could resolve it to void*
I don't think on any of the platforms where ObjC matters sizeof(T*) depends on T, so even if we never figured out the pointee type, the pointer type should still be sane
This might also allow some limited inspection where previously none was possible, so a win



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219540 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new disassembly-format specification so that the disassembler
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> 



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219544 91177308-0d34-0410-b5e6-96231b3b80d8
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



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219546 91177308-0d34-0410-b5e6-96231b3b80d8
Fix unused variable warning from r219544.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219547 91177308-0d34-0410-b5e6-96231b3b80d8
Remove default case from a fully covered switch.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219548 91177308-0d34-0410-b5e6-96231b3b80d8
Reinstate setting addr_width to the result of the computation,
but in the conditional rather than at initialization time.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219549 91177308-0d34-0410-b5e6-96231b3b80d8
Rework the way we pass "run multiple command" options to the various API's that
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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219553 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the build after the recent plugin additions for
AddressSanitizer by adding dependencies and definitions.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219554 91177308-0d34-0410-b5e6-96231b3b80d8
include compiler-rt in build-llvm.pl

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

The new test cases for ASan fail if the llvm build that is used with LLDB doesn't have compiler-rt (because the resulting compiler then cannot build with -fsanitize=address). Let's include compiler-rt in build-llvm.pl script and make sure we actually *build* it by removing the NO_RUNTIME_LIBS=1 argument used in the make line. After this, the ASan tests pass on a fresh svn checkout.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219555 91177308-0d34-0410-b5e6-96231b3b80d8
Add a IsInstrumentationRuntimePresent SB API

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

This adds an SB API into SBProcess:
  bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219560 91177308-0d34-0410-b5e6-96231b3b80d8
Fix cmake build for PluginInstrumentationRuntimeAddressSanitizer.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219576 91177308-0d34-0410-b5e6-96231b3b80d8
llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.

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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219578 91177308-0d34-0410-b5e6-96231b3b80d8
Merge upstream llvm.org r219578 into dev-thread-state-coordinator.

Conflicts:
	source/Plugins/Process/Linux/NativeProcessLinux.cpp
	source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp