| d1ddde0c443e67b37f9303b5bdff19aad9f54fdc |
|
24-May-2013 |
Greg Clayton <gclayton@apple.com> |
<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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182627 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 81a96aa6242f7b559770f5dc62316253cb8cb0d4 |
|
18-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 9acf3699d2bea583b45c762f4cd82b2a4af6131b |
|
12-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
<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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179405 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 226484d8533b19c9a63e5df20d30c37075e51f03 |
|
28-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178262 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 4dd7f537a66878101eb9c355e571af0c44ea5906 |
|
28-Mar-2013 |
Jim Ingham <jingham@apple.com> |
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>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178205 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 952e9dc874944fcdbbb224f3ec4fc2c859376f64 |
|
28-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
<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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 41b5bfe52dbe9dce14bc655d6d786c5c05f08018 |
|
15-Mar-2013 |
Enrico Granata <egranata@apple.com> |
<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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177166 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 0bce9a22354df3f00e68ffd912119a0741753b7f |
|
05-Dec-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12649160>
Added the ability to debug through your process exec'ing itself to the same architecture.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169340 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae |
|
29-Nov-2012 |
Daniel Malea <daniel.malea@intel.com> |
Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 6f01c93497df194b6f2194630a81e87d806ce0e0 |
|
12-Oct-2012 |
Jim Ingham <jingham@apple.com> |
Bunch of cleanups for warnings found by the llvm static analyzer.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165808 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 64a41e221e3a47799ff3ea5eddacb58e86d74be1 |
|
08-Sep-2012 |
Jim Ingham <jingham@apple.com> |
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163439 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 9b124c6bc79c0f650ac52d65d6366f45f30ee31d |
|
08-Sep-2012 |
Jim Ingham <jingham@apple.com> |
Add SetCurrentInlinedDepth API.
In GetFramesUpTo, don't adjust the number of frames for the inlined depth if the number of frames in UINT32_MAX.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163432 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 74d08f1ea720cda87abcc09d6036785a96926ef3 |
|
07-Sep-2012 |
Jim Ingham <jingham@apple.com> |
For now, treat breakpoint hits like regular stops when calculation InlinedStackDepth.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163365 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 1949b1e8eb944bcaf56fdbee52ed9b226b4bc8e5 |
|
06-Sep-2012 |
Jim Ingham <jingham@apple.com> |
When you reach the bottom of the inlined stack, don't say you can do a virtual step.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163341 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 1cc0c05acc4e6f4e95f74c3e4eb1c8847bda4a76 |
|
05-Sep-2012 |
Jim Ingham <jingham@apple.com> |
Turn on the "fancy inlined stepping."
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163246 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 0c8fa2d7dd18ae1816c82846234c45f79142e3df |
|
01-Sep-2012 |
Jim Ingham <jingham@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163044 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| a7d3dc75ec4f46033c3f991f11fb58a058091a85 |
|
11-Jul-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11852100>
The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160071 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 1b584ebc1de8b50fe375cffb5fb33ad13be10046 |
|
05-May-2012 |
Jim Ingham <jingham@apple.com> |
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.)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 6252ea842062c39198558c949d5e09f10422683a |
|
01-Mar-2012 |
Jim Ingham <jingham@apple.com> |
If the unwinder fails to make us a frame 0, make one by hand from the SP & PC.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151793 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| c92468f4c182ec4d2159f031b01391f5d7d473f4 |
|
29-Feb-2012 |
Jim Ingham <jingham@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151744 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| bf97d74c0c3e9a0f7c89fe0cd4a059015ec482d5 |
|
29-Feb-2012 |
Jim Ingham <jingham@apple.com> |
Make the StackFrameList::GetFrameAtIndex only fetch as many stack frames as needed to
get the frame requested.
<rdar://problem/10943135>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151705 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| f4124deeb9532044a38c0774ced872f2709347da |
|
21-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 289afcb5e26c2527a0d2e71f84e780b86bbcf90a |
|
18-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
The second part in thread hardening the internals of LLDB where we make
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150871 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| b4d7fc0c466d446876e5f2d701f0e574dd0be8e7 |
|
17-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
This checking is part one of trying to add some threading safety to our
internals. The first part of this is to use a new class:
lldb_private::ExecutionContextRef
This class holds onto weak pointers to the target, process, thread and frame
and it also contains the thread ID and frame Stack ID in case the thread and
frame objects go away and come back as new objects that represent the same
logical thread/frame.
ExecutionContextRef objcets have accessors to access shared pointers for
the target, process, thread and frame which might return NULL if the backing
object is no longer available. This allows for references to persistent program
state without needing to hold a shared pointer to each object and potentially
keeping that object around for longer than it needs to be.
You can also "Lock" and ExecutionContextRef (which contains weak pointers)
object into an ExecutionContext (which contains strong, or shared pointers)
with code like
ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock());
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150801 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 3e4238d47a6d1a3106f357d2e7b495870721c7ae |
|
04-Nov-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed the Xcode project building of LLVM to be a bit more user friendly:
- If you download and build the sources in the Xcode project, x86_64 builds
by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
Xcode project will download the right LLVM sources and build them from
scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
directory, we will use the sources you have placed in the LLDB directory.
Python can now be disabled for platforms that don't support it.
Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143678 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| d426d6317d2d6cde6b2816315d864d6ea2e8ac0a |
|
07-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10226227>
Fixed the root cause of what was causing an assertion to fire during single stepping. We had an issue with the inlined stack frames where when we had inlined frames that were not in the first concrete frame where we passed the wrong PC down. We needed to decrement the PC by one for these frames to make
sure we are using the same address that did the symbol context lookup.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141349 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 840a992018e4bc55f18e5b68815600fa6870f8d9 |
|
05-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed a crasher where the m_frames collection was being accessed without
using the mutex.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141160 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 2f57db09a49f2a05a620b8163bbe1e748a46ec73 |
|
01-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the the code that figures out the inlined stack frames given a
symbol context that represents an inlined function. This function has been
renamed internally to:
bool
SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc,
SymbolContext &next_frame_sc,
Address &next_frame_pc) const;
And externally to:
SBSymbolContext
SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc,
SBAddress &parent_frame_addr) const;
The correct blocks are now correctly calculated.
Switched the stack backtracing engine (in StackFrameList) and the address
context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...)
so all inlined callstacks will match exactly.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140910 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 |
|
20-Sep-2011 |
Jason Molenda <jmolenda@apple.com> |
Update declarations for all functions/methods that accept printf-style
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| fdf24efe672bf3fa041cdbebd2d7f406b11882bd |
|
09-Sep-2011 |
Jim Ingham <jingham@apple.com> |
Move the SourceManager from the Debugger to the Target. That way it can store the per-Target default Source File & Line.
Set the default Source File & line to main (if it can be found.) at startup. Selecting the current thread & or frame resets
the current source file & line, and "source list" as well as the breakpoint command "break set -l <NUM>" will use the
current source file.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 0a77f90197f2e115208c45c9e7f28ef745da9c95 |
|
25-Aug-2011 |
Johnny Chen <johnny.chen@apple.com> |
Fix compilation error with DEBUG_STACK_FRAMES defined, patch by Filipe Cabecinhas!
With some slight modification.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138563 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| abe0fed36d83e1c37af9dae90c2d25db742b4515 |
|
18-Apr-2011 |
Greg Clayton <gclayton@apple.com> |
Centralized a lot of the status information for processes,
threads, and stack frame down in the lldb_private::Process,
lldb_private::Thread, lldb_private::StackFrameList and the
lldb_private::StackFrame classes. We had some command line
commands that had duplicate versions of the process status
output ("thread list" and "process status" for example).
Removed the "file" command and placed it where it should
have been: "target create". Made an alias for "file" to
"target create" so we stay compatible with GDB commands.
We can now have multple usable targets in lldb at the
same time. This is nice for comparing two runs of a program
or debugging more than one binary at the same time. The
new command is "target select <target-idx>" and also to see
a list of the current targets you can use the new "target list"
command. The flow in a debug session can be:
(lldb) target create /path/to/exe/a.out
(lldb) breakpoint set --name main
(lldb) run
... hit breakpoint
(lldb) target create /bin/ls
(lldb) run /tmp
Process 36001 exited with status = 0 (0x00000000)
(lldb) target list
Current targets:
target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
* target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) target select 0
Current targets:
* target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) bt
* thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1
frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16
frame #1: 0x0000000100000b64 a.out`start + 52
Above we created a target for "a.out" and ran and hit a
breakpoint at "main". Then we created a new target for /bin/ls
and ran it. Then we listed the targest and selected our original
"a.out" program, so we showed two concurent debug sessions
going on at the same time.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129695 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| dbeb3e1e038a75f00fd565203839020e1d00a7c6 |
|
11-Apr-2011 |
Stephen Wilson <wilsons@start.ca> |
Order of initialization lists.
This patch fixes all of the warnings due to unordered initialization lists.
Patch by Marco Minutoli.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 5c4b1607e8783a3d3f1f28fa66fcaa89ac246bd1 |
|
31-Mar-2011 |
Jim Ingham <jingham@apple.com> |
Add GetFrameWithStackID to the StackFrameList and the Thread (which routes to its StackFrameList.)
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128592 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 08d7d3ae16110aa68ed40c161eac8571aeb94cd9 |
|
06-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed issues with RegisterContext classes and the subclasses. There was
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| a830adbcd63d1995a01e6e18da79893c1426ca43 |
|
04-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
There are now to new "settings set" variables that live in each debugger
instance:
settings set frame-format <string>
settings set thread-format <string>
This allows users to control the information that is seen when dumping
threads and frames. The default values are set such that they do what they
used to do prior to changing over the the user defined formats.
This allows users with terminals that can display color to make different
items different colors using the escape control codes. A few alias examples
that will colorize your thread and frame prompts are:
settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n'
settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n'
A quick web search for "colorize terminal output" should allow you to see what
you can do to make your output look like you want it.
The "settings set" commands above can of course be added to your ~/.lldbinit
file for permanent use.
Changed the pure virtual
void ExecutionContextScope::Calculate (ExecutionContext&);
To:
void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&);
I did this because this is a class that anything in the execution context
heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell
you what it was really trying to do unless you look at the parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115485 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| ccd584dccb920cdb028de69950774c3bcdc025ec |
|
23-Sep-2010 |
Jim Ingham <jingham@apple.com> |
Add GetSP to the StackFrame.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114674 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 69aa5d9a7620a183cdc4da12cc87ea82e2ffcbf9 |
|
07-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Added more API to lldb::SBBlock to allow getting the block
parent, sibling and first child block, and access to the
inline function information.
Added an accessor the StackFrame:
Block * lldb_private::StackFrame::GetFrameBlock();
LLDB represents inline functions as lexical blocks that have
inlined function information in them. The function above allows
us to easily get the top most lexical block that defines a stack
frame. When there are no inline functions in function, the block
returned ends up being the top most block for the function. When
the PC is in an inlined funciton for a frame, this will return the
first parent block that has inlined function information. The
other accessor: StackFrame::GetBlock() will return the deepest block
that matches the frame's PC value. Since most debuggers want to display
all variables in the current frame, the Block returned by
StackFrame::GetFrameBlock can be used to retrieve all variables for
the current frame.
Fixed the lldb_private::Block::DumpStopContext(...) to properly
display inline frames a block should display all of its inlined
functions. Prior to this fix, one of the call sites was being skipped.
This is a separate code path from the current default where inlined
functions get their own frames.
Fixed an issue where a block would always grab variables for any
child inline function blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113195 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 5205f0b6585a127acc6ed210021abb6091220a89 |
|
03-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope.
Added extra logging for stepping.
Fixed an issue where cached stack frame data could be lost between runs when
the thread plans read a stack frame.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112973 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 72b7158235500ae6d4b69ed378cbc36bf6e5cbe1 |
|
02-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Added a new bool parameter to many of the DumpStopContext() methods that
might dump file paths that allows the dumping of full paths or just the
basenames. Switched the stack frame dumping code to use just the basenames for
the files instead of the full path.
Modified the StackID class to no rely on needing the start PC for the current
function/symbol since we can use the SymbolContextScope to uniquely identify
that, unless there is no symbol context scope. In that case we can rely upon
the current PC value. This saves the StackID from having to calculate the
start PC when the StackFrame::GetStackID() accessor is called.
Also improved the StackID less than operator to correctly handle inlined stack
frames in the same stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112867 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 4fb08150367853dae24bb92904356788e919a72f |
|
30-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Clarified the intent of the SymbolContextScope class in the header
documentation. Symbol now inherits from the symbol
context scope so that the StackID can use a "SymbolContextScope *"
instead of a blockID (which could have been the same as some other
blockID from another symbol file).
Modified the stacks that are created on subsequent stops to reuse
the previous stack frame objects which will allow for some internal
optimization using pointer comparisons during stepping.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 870a1cdb923ce708d474af357dd1fea3d063ab97 |
|
27-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Made it so we update the current frames from the previous frames by doing STL
swaps on the variable list, value object list, and disassembly. This avoids
us having to try and update frame indexes and other things that were getting
out of sync.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112301 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 1d66ef5d31a8326d5495f56b0cfbf2fd1bff67d8 |
|
27-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Simplified the StackFrameList class down to a single frames list again
instead of trying to maintain the real frame list (unwind frames) and an
inline frame list. The information is cheap to produce when we already have
looked up a block and was making stack frame uniquing difficult when trying
to use the previous stack when making the current stack.
We now maintain the previous value object lists for common frames between
a previous and current frames so we will be able to tell when variable values
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112277 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| c833295baeec641086f536e78050388af36784f8 |
|
26-Aug-2010 |
Jim Ingham <jingham@apple.com> |
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| f40e30823926f27e3cb9364f3c8fe2e4be0c7658 |
|
26-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the inline stack frame code one more time to prepare for inlined
code stepping. Also we now store the stack frames for the current and previous
stops in the thread in std::auto_ptr objects. When we create a thread stack
frame list we pass the previous frame into it so it can re-use the frames
and maintain will allow for variable changes to be detected. I will implement
the stack frame reuse next.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112152 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 782b9ccd9f2b290585cd6bb4c1f0cc6cb7e22e15 |
|
25-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the inline backtrace code even more by moving all stack backtracing
functionality into StackFrameList. This will allow us to copy the previous
stack backtrace from the previous stop into another variable so we can re-use
as much as possible from the previous stack backtrace.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112007 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|
| 24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrameList.cpp
|