Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends ar

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.

Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.

This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.

I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.

<rdar://problem/15314068>

llvm-svn: 193907

show more ...

Mark the selected frame of the selected thread in backtraces.

<rdar://problem/15252474>

llvm-svn: 192989

<rdar://problem/13643315>

Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContext

<rdar://problem/13643315>

Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses.

llvm-svn: 182627

show more ...

After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.

llvm-svn: 179805

Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can

Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.

llvm-svn: 179779

show more ...

<rdar://problem/13491977>

Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Proces

<rdar://problem/13491977>

Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems

llvm-svn: 179405

show more ...

Be sure to take the mutex when the destructor is called in case other threads are using these lists and those other threads have the mutex locked.

llvm-svn: 178262

Protect against the case where the current inlined depth is wrong, and leads us to think we can't even get the
frame at index 0. We should ALWAYS be able to get that.

<rdar://problem/13497571>

llv

Protect against the case where the current inlined depth is wrong, and leads us to think we can't even get the
frame at index 0. We should ALWAYS be able to get that.

<rdar://problem/13497571>

llvm-svn: 178205

show more ...

<rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logg

<rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191

show more ...

<rdar://problem/13194155>

Fixing an issue where threads and frames could get out of sync and cause ValueObjects to fail to retrieve their values correctly

llvm-svn: 177166

<rdar://problem/12649160>

Added the ability to debug through your process exec'ing itself to the same architecture.

llvm-svn: 169340

Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945

Bunch of cleanups for warnings found by the llvm static analyzer.

llvm-svn: 165808

Fiddle with the heuristic about where to set the stop point in a nested inline stack when we get there by breakpoint. If we hit a user breakpoint, I set the stop point to the bottom-most frame 'caus

Fiddle with the heuristic about where to set the stop point in a nested inline stack when we get there by breakpoint. If we hit a user breakpoint, I set the stop point to the bottom-most frame 'cause that's what we did before.

<rdar://problem/12258999> Setting breakpoint in always inline function is stopping in function above it

llvm-svn: 163439

show more ...

Add SetCurrentInlinedDepth API.
In GetFramesUpTo, don't adjust the number of frames for the inlined depth if the number of frames in UINT32_MAX.

llvm-svn: 163432

For now, treat breakpoint hits like regular stops when calculation InlinedStackDepth.

llvm-svn: 163365

When you reach the bottom of the inlined stack, don't say you can do a virtual step.

llvm-svn: 163341

Turn on the "fancy inlined stepping."

llvm-svn: 163246

Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of in

Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately. So for now its off.

llvm-svn: 163044

show more ...

<rdar://problem/11852100>

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

llvm-svn: 160071

Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mu

Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...

Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)

llvm-svn: 156221

show more ...

If the unwinder fails to make us a frame 0, make one by hand from the SP & PC.

llvm-svn: 151793

Use the correct (computed by the unwinder) CallFrameAddress as the CFA for Frame 0 rather than using the stack pointer which is not constant over the life of the frame.

llvm-svn: 151744

Make the StackFrameList::GetFrameAtIndex only fetch as many stack frames as needed to
get the frame requested.
<rdar://problem/10943135>

llvm-svn: 151705

Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto

Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.

Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.

llvm-svn: 151009

show more ...