llvm-svn: 160338

the state of the unwind instructions once the prologue has finished.  If it hits an
early return epilogue in the middle of the function, re-instate the prologue after that
epilogue has completed so that we can still unwind for cases where the flow of control
goes past that early-return.  <rdar://problem/11775059>

Move the UnwindPlan operator== definition into the .cpp file, expand the definition a bit.

Add some casts to a SBCommandInterpreter::HandleCompletion() log statement so it builds without
warning on 64- and 32-bit systems.

llvm-svn: 160337

someone has set our file descriptor to -1 and crash in FD_SET...
<rdar://problem/11653966>

llvm-svn: 160336

<rdar://problem/11672978> Fixing an issue where an ObjC object might come out without a description because the expression used to obtain it would timeout before running to completion

llvm-svn: 160326

a shared pointer to ease some memory management issues with a patch
I'm working on.

The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again.  A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.

llvm-svn: 160214

llvm-svn: 160212

Allow "frame variable" to find ivars without the need for "this->" or "self->".  

llvm-svn: 160211

Fixing a buildbot issue in GDBRemoteCommunicationServer due to an undefined constant in latest commit

llvm-svn: 160208

<rdar://problem/11782789> Changes to the watchpoint implementation on ARM so that we single-step before stopping at the WP. This is necessary because on ARM the WP triggers before the opcode is actually executed, so we would be unable to continue since we would keep hitting the WP. We work around this by disabling the WP, single stepping and then putting the WP back in place.

llvm-svn: 160199

with one armv7 unwind.  I'll look at updating this or finding a
different way of fixing it later tonight.

llvm-svn: 160198

current symbol context is a C++ or Objective-C
instance method.

Specifically, ensure that we fetch information
on the current block, not just the current
function.

llvm-svn: 160195

Add accessors on process to get & set the selected thread by IndexID (useful since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused.

llvm-svn: 160187

LLDB to distinguish between multiple anonymous
structs/unions in the same class.

<rdar://problem/11466212>

llvm-svn: 160186

llvm-svn: 160181

llvm-svn: 160180

llvm-svn: 160158

Make the setting for "target.process.thread.step-avoid-regexp" work for inlined functions, not just concrete top level functions.

llvm-svn: 160151

frame pointer overwritten with the caller's fp value, return to 
expressing the CFA in terms of the stack pointer.
<rdar://problem/11855862>

llvm-svn: 160150

Also remove our dependency on UIKit & AppKit.
Cleaned up the project files a bit.

<rdar://problem/11814498>

llvm-svn: 160147

Fixed issues that could happen when the UUID doesn't change in a binary and old stale debug info could end up being used.

llvm-svn: 160145

return sections that don't have valid modules.

<rdar://problem/11605824>

llvm-svn: 160141

Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects. 

We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache).

Now all of this is fixed and everything goes away between runs.

llvm-svn: 160140

Mac OS X, because the UUID is the same for all
OpenCL-generated dylibs and therefore would
conflict.

<rdar://problem/11620586>

llvm-svn: 160135

path passed with -w

Test this functionality.

llvm-svn: 160130

Add a command channel to wait on along with the file descriptor the ConnectionFileDescriptor class is managing, so we can always pop ourselves out of our select call regardless of how well behaved the channel we are talking to is.

<rdar://problem/11448282>

llvm-svn: 160100

generation of the FDE index.

<rdar://problem/11813705>

llvm-svn: 160099

UnwindPlans for a function.  This specifically does not use any
previously-generated UnwindPlans so if any logging is performed
while creating the UnwindPlans, it will be repeated.  This is
useful for when an lldb stack trace is not correct and you want
to gather diagnostic information from the user -- they can do 
log enable -v lldb unwind, image show-unwind of the function, and
you'll get the full logging as the UnwindPlans are recreated.

llvm-svn: 160095

llvm-svn: 160086

Modifying the "address" format, which prints a pointer and a description of what it points to, to detect when the deref of that pointer points to something valid. So if you have:

    % cat sp.cpp 
    #include <tr1/memory>

    class A
    {
    public:
        A (): m_i (12) {}
        virtual ~A() {}
    private:
        int m_i;
    };

    int main (int argc, char const *argv[], char const *envp[])
    {
        A *a_pointers[2] = { NULL, NULL };
        A a1;
        A a2;
        a_pointers[0] = &a1;
        a_pointers[1] = &a2;
        return 0;
    }


And you stop at the "return 0", you can now read memory using the "address" format and see:

(lldb) memory read --format address `&a_pointers`
0x7fff5fbff870: 0x00007fff5fbff860 -> 0x00000001000010b0 vtable for A + 16
0x7fff5fbff878: 0x00007fff5fbff850 -> 0x00000001000010b0 vtable for A + 16
0x7fff5fbff880: 0x00007fff5fbff8d0
0x7fff5fbff888: 0x00007fff5fbff8c0
0x7fff5fbff890: 0x0000000000000001
0x7fff5fbff898: 0x36d54c275add2294
0x7fff5fbff8a0: 0x00007fff5fbff8b0
0x7fff5fbff8a8: 0x0000000100000bb4 a.out`start + 52

Note the extra dereference that was applied to 0x00007fff5fbff860 and 0x00007fff5fbff850 so we can see that these are "A" classes.

llvm-svn: 160085

If we hit a breakpoint but there's a thread specifier which doesn't match this thread, return no stop reason.

llvm-svn: 160080

llvm-svn: 160079

the fact that a process exited while running a thread
plan.  For example, if a user types the expression

expr (void)exit(0)

then the process terminates but LLDB does not notify
listeners like Xcode that this occurred.

<rdar://problem/11845155>

llvm-svn: 160077

Fixed an issue where if you ask to search the global list of modules for a module with "target modules list", if it found a match in the current target, it would skip looking at the global list. Now if you ask for the global list, we use it and skip the target.

llvm-svn: 160072

The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them.

llvm-svn: 160071

loop if "memory read" is run with the -t option and
the type name contains a keyword like "struct" that
isn't followed by a space.  Now if a keyword isn't
followed by a space we continue searching after it,
instead of at the beginning of the type name.

Also optimized the code to not call strlen() on
a fixed set of statically-declared constant strings.

llvm-svn: 160016

Turning the interpreter mutex into a static global to avoid a potential leak. Might need to be turned back into a pointer if it causes issues with the destructor chain.

llvm-svn: 160012

<rdar://problem/11751427> Fixing an issue where multiple threads could concurrently try and initialize Python and cause crashes

llvm-svn: 160008

Improve dynamic type resolution efficiency by looking for the type in the module that contains the vtable symbol first and only look for the first match. If we don't find anything, _then_ move on to the rest of the modules in the target and watch out for multiple matches.

llvm-svn: 159975

llvm-svn: 159929

llvm-svn: 159927