Make sure SectionLoadHistory::GetCurrentSectionLoadList () is thread safe.

<rdar://problem/15818525>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209485 91177308-0d34-0410-b5e6-96231b3b80d8
The UnwindTable (one per module) used to hand out shared pointers
to its unwind assembly profiler to all of the FuncUnwinders (one
per symbol) under it.  If lldb is running multiple targets, you
could get two different FuncUnwinders in the same Module trying
to use the same llvm disassembler simultaneously and that may be
a re-entrancy problem.  

Instead, the UnwindTable has the unwind assembly profiler and when
the FuncUnwinders want to use it, they get exclusive access to
the assembly profiler until they're done using it.
<rdar://problem/16992332> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209488 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r209488; Greg suggests a different approach.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209492 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of having an UnwindTable own a single assembly profiler, 
and sharing it with all of its FuncUnwinders, have each FuncUnwinder
create an AssemblyProfiler on demand as needed.  I was worried that
the cost of creating the llvm disassemblers would be high for this
approach but it's not supposed to be an expensive operation, and it
means we don't need to add locks around this section of code.
<rdar://problem/16992332> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209493 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed the Symbol code to resolve the callable address
of the symbol itself rather than forcing clients to do
it.  This simplifies the logic for the expression
parser a great deal.

<rdar://problem/16935324>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209494 91177308-0d34-0410-b5e6-96231b3b80d8
Added gdb remote tests to verify $Hg{thread-id}.

Added test to check that each thread reported by $q{f,s}ThreadInfo
can be switched to by $Hg, verified by a follow-up $qC.

Modified test exe to accept "thread:new" to create a new thread 
that runs and sleeps for 5 seconds.

@llgs_test/@debugserver_test now buffer output.
   
llgs and debugserver gdbremote protocol tests now collect $O notification
output into the context returned from expect_lldb_gdbserver_replay.
context["O_count"] is an integer indicating the number of $O packets
collected during the replay, and context["O_content"] contains the
accumulated hex-decoded text output by the inferior (stdout and stderr).

Modified the $O check test to check the accumulated output rather than
a direct $O packet.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209560 91177308-0d34-0410-b5e6-96231b3b80d8
Remove some unnecessary comments from previous check-in.

Removed a "done" TODO comment.

Moved some helper methods to the top of the unit test.

Removed some commented out code I was considering implementing
before I came up with a better overall approach.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209561 91177308-0d34-0410-b5e6-96231b3b80d8
Add a lock ivar to the Platform so that multiple Targets
trying to populate the list of trap handler names at
the same time don't conflict with one another.
<rdar://problem/17011969> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@209563 91177308-0d34-0410-b5e6-96231b3b80d8
Merge upstream llvm.org r209563 into dev-tfiala-native-protocol-linux-x86_64

Conflicts:
	test/tools/lldb-gdbserver/TestLldbGdbServer.py
Fixed llgs Linux attach bug with wrong thread id.

The attach-to-process NativeProcessLinux code was recording
threads at attach time using the wrong id - using the pid rather
than the thread's tid.  This manifested as the second of all
attached threads always triggering the "same thread added" assert
in addition to losing info on non-main-thread tids.