Fix the Windows build by removing the unused lldb_python_module.cmake inclusion from CMakeLists.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216392 91177308-0d34-0410-b5e6-96231b3b80d8
Change back all paths returns for lldb::PathType enumerations from HostInfo::GetLLDBPath() to return the directories in the FileSpec.m_directory field to match previous implementations. This change previously broke some path stuff in upstream branches.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216398 91177308-0d34-0410-b5e6-96231b3b80d8
Added a test case to ensure lldb::SBHostOS::GetLLDBPath() doesn't return lldb::SBFileSpec objects with the filename filled in for directory paths.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216399 91177308-0d34-0410-b5e6-96231b3b80d8
On x86 & x86_64, try to use eh_frame for frame 0.

We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.

Change by Tong Shen.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216406 91177308-0d34-0410-b5e6-96231b3b80d8
Add 64-bit eh_frame section CFI support.

In practice, 64bit eh_frame is not used even for x86_64 binaries. The main reason is in eh_frame we almost always use pc-relative addressing, so addresses are within 32bits and gcc just sticks to 32bit eh_frame.

I generated 64bit eh_frame for Android Java runtime and unwind successfully in gdb, and in lldb with this patch.

Patch by Tong Shen.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216409 91177308-0d34-0410-b5e6-96231b3b80d8
Have augment_unwind_plan_from_call_site update the UnwindPlan 
name/from-compiler settings to indicate that it was augmented
by assembly profiling.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216412 91177308-0d34-0410-b5e6-96231b3b80d8
Copy unwind plan instead of modifying it directly, so "image show-unwind" prints different plans for asynchronous and synchronous.

Change by Tong Shen.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216416 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up the coding conventions in UnwindAssembly-x86.cpp a little bit.
I wrote this originally as a part of an unwind library that was using
a different coding convention and some of that old style remained after
its integration into lldb.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216419 91177308-0d34-0410-b5e6-96231b3b80d8
Remove trailing whitespace from lines in UnwindAssembly-x86.cpp.  No other changes.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216420 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the hostname part from compilation directories, if supplied by 
DWARF2/3 compliant producers.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216440 91177308-0d34-0410-b5e6-96231b3b80d8
Refactored existing gdb-remote qProcessInfo tests into separate python file.

I'm about to add some more qProcessInfo tests so I wanted to first pull them out
of the monolithic TestLldbGdbServer test case class.

Related to http://llvm.org/bugs/show_bug.cgi?id=20755


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216465 91177308-0d34-0410-b5e6-96231b3b80d8
Fix llgs to send triple for non-Apple platforms and lldb to interpret correctly.

This change addresses this bug:
http://llvm.org/bugs/show_bug.cgi?id=20755

This change:
* Modifies llgs to send triple instead of cputype and cpusubtype when not on Apple platforms in qProcessInfo.
* Modifies lldb's GDBRemoteCommunicationClient to handle the triple returned from qProcessInfo if given.
  When given, it will prefer to use triple over cputype and cpusubtype.
* Adds gdb-remote protocol tests to verify that cputype and cpusubtype are specified on darwin, and that triple is specified on Linux.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216470 91177308-0d34-0410-b5e6-96231b3b80d8
Added a couple more gdb-remote tests to ensure qProcessInfo on darwin is not defining triple.

And likewise for qProcessInfo on Linux, but ensures cputype/cpusubtype is not defined.  The
Apple case is the more important one, since we take a slightly different path to initialize
ProcessGDBRemote-related remote host/process info if triple is present.

Related to http://llvm.org/bugs/show_bug.cgi?id=20755.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216473 91177308-0d34-0410-b5e6-96231b3b80d8
Add an API on ValueObject to generate a 'synthetic child' of base class type. Note that in this commit, the term synthetic child is not meant to refer to data formatters, but to the programmatically-generated children stored inside a ValueObject itself

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216483 91177308-0d34-0410-b5e6-96231b3b80d8
[dwarf] Add new language enumerations.

This updates the DWARF language identifiers to include recent additions to
the DWARF 5 specification (draft).


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216486 91177308-0d34-0410-b5e6-96231b3b80d8
It was pointed out to me that an offset of 0 makes sense for ObjC, but not always for C++, and this API claims to be general enough that it should not drop C++ usability on the floor for no good reason. Fix it with an explicit offset argument

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216487 91177308-0d34-0410-b5e6-96231b3b80d8
Don't have ProcessMachCore::CanDebug use the Target's arch when
creating the ModuleSpec to load the core file - we won't have a fat
core file and we can end up with cpu subtype mismatches if the core
file header isn't written out completely accurately.  We need to
be a little loose in this particular case.
<rdar://problem/17843388>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216498 91177308-0d34-0410-b5e6-96231b3b80d8
There seems to be no sane reason for a test case to enable logging every time it runs.. probably leftover from when I was debugging it

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216502 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up after the multithreaded test case finishes.

Patch by Sean Callanan.
<rdar://problem/18140875> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216504 91177308-0d34-0410-b5e6-96231b3b80d8
Add __NSCFDictionary to the list of NSDictionary-like types for which we know to generate synthetic children

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@216513 91177308-0d34-0410-b5e6-96231b3b80d8