The change previously committed as 220983 broke large binary memory reads. I kept the "idx - 1" fix from 220983, but reverted the while loop that was incorrectly added.

The details are: large packets (like large memory reads (m packets) or large binary memory reads (x packet)) can get responses that come in across multiple read() calls. The while loop that was added meant that if only a partial packet came in (like only "$abc" coming for a response) GDBRemoteCommunication::CheckForPacket() was called, it would deadlock in the while loop because no more data is going to come in as this function needs to be called again with more data from another read. So the original fix will need to be corrected and resubmitted.

<rdar://problem/18853744>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221181 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed a test suite error on MacOSX where people were using ".data" as the data section name for all file formats. Instead fix the test by finding the section by section type so the test is agnostic to the file format (and passes on MacOSX).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221196 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed a test suite error on MacOSX where people were using ".data" as the data section name for all file formats. Instead fix the test by finding the section by section type so the test is agnostic to the file format (and passes on MacOSX).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221197 91177308-0d34-0410-b5e6-96231b3b80d8
Fix this test to set a breakpoint at the correct location that will always get hit so it doesn't intermittently fail on MacOSX.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221201 91177308-0d34-0410-b5e6-96231b3b80d8
Implement a framework for live debugging on Windows.

When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.

These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process.  This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.

Reviewed by: Scott Graham

Differential Revision: http://reviews.llvm.org/D6037

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221207 91177308-0d34-0410-b5e6-96231b3b80d8
Added a test case for reading ivars from the
Objective-C runtime.  We'll need to do more
(subclasses, partially-defined classes, etc.)
but this tests that at least the basics work.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221208 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed SBTarget::ReadMemory() to work correctly and the TestTargetAPI.py test case that was reading target memory in TargetAPITestCase.test_read_memory_with_dsym and TargetAPITestCase.test_read_memory_with_dwarf.

The problem was that SBTarget::ReadMemory() was making a new section offset lldb_private::Address by doing:


size_t
SBTarget::ReadMemory (const SBAddress addr,
                      void *buf,
                      size_t size,
                      lldb::SBError &error)
{
        ...
        lldb_private::Address addr_priv(addr.GetFileAddress(), NULL);
        bytes_read = target_sp->ReadMemory(addr_priv, false, buf, size, err_priv);


This is wrong. If you get the file addresss from the "addr" argument and try to read memory using that, it will think the file address is a load address and it will try to resolve it accordingly. This will work fine if your executable is loaded at the same address (no slide), but it won't work if there is a slide.

The fix is to just pass along the "addr.ref()" instead of making a new addr_priv as this will pass along the lldb_private::Address that is inside the SBAddress (which is what we want), and not always change it into something that becomes a load address (if we are running), or abmigious file address (think address zero when you have 150 shared libraries that have sections that start at zero, which one would you pick). The main reason for passing a section offset address to SBTarget::ReadMemory() is so you _can_ read from the actual section + offset that is specified in the SBAddress. 




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221213 91177308-0d34-0410-b5e6-96231b3b80d8
After we've completed a full backtrace, we'll have one frame which
is "invalid" -- it is past the end of the stack trace.  Add a new
method IsCompletedStackWalk() so we can tell if an invalid stack
frame is from a complete backtrace or if it might be worth re-trying
the last unwind with a different method.

This fixes the unwinder problems Ryan Brown was having with go
programs.  The unwinder can (under the right circumstances) still
destructively replace unwind plans permanently - I'll work on
that in a different patch.  

<rdar://problem/18683658> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221229 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a bunch of [-Werror,-Winconsistent-missing-override] errors.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221231 91177308-0d34-0410-b5e6-96231b3b80d8
Fix one more [-Werror,-Winconsistent-missing-override] error.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221232 91177308-0d34-0410-b5e6-96231b3b80d8
Back out r221229 -- instead of trying to identify the end of the unwind,
let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.

This fix is for <rdar://problem/18683658>.  

I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios 
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719> 
that I've fixed over the last 6-9 months.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221238 91177308-0d34-0410-b5e6-96231b3b80d8
Add one extra sanity check to RegisterContextLLDB::TryFallbackUnwindPlan
so it doesn't try the arch default if a comiler-generated (eh_frame,
compact unwind info) based unwind plan has failed.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221239 91177308-0d34-0410-b5e6-96231b3b80d8
Add recognition for another x86 epilogue sequence (ret followed by
a nop).  Fixes an instruction stepping problem when trying to step
over the final instructions of an epilogue.
<rdar://problem/18068877> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221241 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the build for LLVM changes

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221286 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a problem where ValueObjectVariable was not correctly setting its 'has value changed' flag for scalar valued variables. This fixes rdar://17851144

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221298 91177308-0d34-0410-b5e6-96231b3b80d8
for Siva Chandra: Fix compilation of StringPrinter.cpp with GCC. Differential Revision:  http://reviews.llvm.org/D6122

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221310 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid building lldb-mi when --enable-werror is set
as it doesn't build and is optional.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221315 91177308-0d34-0410-b5e6-96231b3b80d8
Rename some classes in ProcessWindows.

Renamed monitor -> driver, to make clear that the implementation here
is in no way related to that of other process plugins which have also
implemented classes with similar names such as DebugMonitor.

Also created a DebugEventHandler interface, which will be used by
implementors to get notified when debugging events happen in the
inferiors.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221322 91177308-0d34-0410-b5e6-96231b3b80d8
for Oleksiy Vyalov - Redirect stdin, stdout and stderr to /dev/null when launching LLGS process. Differential Revision: http://reviews.llvm.org/D6105

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221324 91177308-0d34-0410-b5e6-96231b3b80d8
Fix lldb build error due to llvm changes. (llvm trunk@221350)