llvm-svn: 180898

Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar.

llvm-svn: 180896

in debug information more aggressive.  Emitting
classes containing these methods causes crashes in
Clang when dealing with complex code bases.

<rdar://problem/12640887>

llvm-svn: 180895

to report proper errors when the size is not
correct.

<rdar://problem/13784456>

llvm-svn: 180888

<rdar://problem/13723772>

Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.

A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.

llvm-svn: 180886

- TODO: Support extended register sets on FreeBSD.

Patch by Samuel Jacob.

llvm-svn: 180879

- Required for platform-independant handling of general purpose registers (i.e. for core dumps).

Thanks to Samuel Jacob for this patch.

llvm-svn: 180878

- Also minor improvements to the comments and the expected results.

llvm-svn: 180876

http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3810
http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/builds/2754

llvm-svn: 180870

llvm-svn: 180868

AppendMessage("") is called.  This idiom is used in a handful of places
right now (e.g. to put space between different threads in 'bt all') but
the empty newline is being omitted instead of emitted.
<rdar://problem/13753830> 

llvm-svn: 180841

out of it.

llvm-svn: 180835

Linux; marking as such.

llvm-svn: 180832

case of ProcessGDBRemote the stub we are talking to) know how to do that.

rdar://problem/13680832

llvm-svn: 180831

llvm-svn: 180830

rdar://problem/12020085

llvm-svn: 180829

llvm-svn: 180828

terminate the command early if we happen to have an invalid load
address.

llvm-svn: 180826

about which kernel binary lldb is referring to.

llvm-svn: 180821

Dynamic type resolution not working for typedef's such as the __ptr_ member in the C++11 std::shared_ptr.

llvm-svn: 180818

functions can be called by basename.

<rdar://problem/13709855>

llvm-svn: 180814

UInts even if their contents were set as bytes.
This makes expressions using registers work
better, especially with core files.

<rdar://problem/13743427>

llvm-svn: 180810

Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write

llvm-svn: 180803

finish-swig-Python-LLDB.sh to create a new lldb.diagnose subdirectory
in the LLDB framework; the first diagnostic command in this directory
is diagnose-unwind.  There may be others added in the future.

Users can load these diagnostic tools into their session with 
"script import lldb.diagnose".

llvm-svn: 180768

give up if it couldn't find the address for the
first symbol it found with a particular name and
type.

<rdar://problem/13748253>

llvm-svn: 180764

an assertion if we attempted to get the size of one.

<rdar://problem/13748253>

llvm-svn: 180763

lldb_private::StopInfo now holds onto a ThreadWP (a std::weak_ptr<lldb_private::Thread>) in case the thread goes away while the stop info still exists.

llvm-svn: 180749

Avoiding a potentially memory allocating code path in the Python InputReader's CTRL+C handling code path - this can potentially cause a deadlock while interrupting a user-made Python command

llvm-svn: 180726

Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules:

std::string
Module::GetSpecificationDescription () const;

This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.

llvm-svn: 180717

llvm-svn: 180713

print the disassembly context around $pc -- just print the filename and line number, even if we 
can't show the source code.  Previously if the source file was not available, lldb would print
the source filename & line number and assembly.  
<rdar://problem/13072951> 

llvm-svn: 180706

will run xcode-select --print-path to find the currently selected 
Xcode developer directory.  Mostly useful for when lldb is not being run out
of the /Applications/Xcode.app bundle so it can't locate the iOS or
kernel SDKs.

llvm-svn: 180705

with directories, without increasing the size of the FileSpec object.
GetPath() returns a std::string of the full pathname of the file.
IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink()
can be used instead of getting the FileType() and comparing it to an enum.

Update PlatformDarwinKernel to use these new methods.

llvm-svn: 180704

mostly related to management of the stack frame
for the interpreter.

  - First, if the expression can be interpreted,
    allocate the stack frame in the target process
    (to make sure pointers are valid) but only
    read/write to the copy in the host's memory.

  - Second, keep the memory allocations for the
    stack frame and the materialized struct as
    member variables of ClangUserExpression.  This
    avoids memory allocations and deallocations
    each time the expression runs.

<rdar://problem/13043685>

llvm-svn: 180664

null pointer.

<rdar://problem/13745684>

llvm-svn: 180663

access to 'z' where 'z' was not in scope.

llvm-svn: 180662

Synthetic children provider for NSOrderedSet

llvm-svn: 180655

presence of malformed class types.

<rdar://problem/13740646>

llvm-svn: 180645

llvm-svn: 180636

Mark tests as expected fail for Linux due to not being able to call/print c++ demangled functions in the global namespace (bugzilla 15854).

llvm-svn: 180623