Commit Graph

82 Commits

Author SHA1 Message Date
Jason Molenda a6e9130d52 Add logging for the SB API which creates extended
threads.

Take a stab at fixing the too-soon freeing of the extended
backtrace thread list in Process.
<rdar://problem/15496603> 

llvm-svn: 195104
2013-11-19 05:44:41 +00:00
Jason Molenda 8ee9cb5891 Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() method
(and same thing to Thread base class) which can be used when looking
at an ExtendedBacktrace thread; it will try to find the IndexID() of
the original thread that was executing this backtrace when it was
recorded.  If lldb can't find a record of that thread, it will return
the same value as IndexID() for the ExtendedBacktrace thread.

llvm-svn: 194912
2013-11-16 01:24:22 +00:00
Jason Molenda 008c45f1a1 Change SBThread::GetExtendedBacktrace to
SBThread::GetExtendedBacktraceThread to make it more clear what is
being returned.

llvm-svn: 194531
2013-11-12 23:33:32 +00:00
Jason Molenda 7a2f7904bf The Threads created when requesting extended backtraces need to be owned by
something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068> 

llvm-svn: 194366
2013-11-11 05:19:34 +00:00
Jason Molenda 02706c3216 Add History subclasses for Thread, Unwind, RegisterContext.
Still working out some of the details of these classes but 
I wanted to get the overall structure checked in.
<rdar://problem/15314068> 

llvm-svn: 194245
2013-11-08 04:59:54 +00:00
Jason Molenda 95d005c789 Rename extended backtrace methods to take out the "ThreadOrigin"
bit from the method names.
<rdar://problem/15314369> 

llvm-svn: 194122
2013-11-06 03:07:33 +00:00
Jason Molenda 5dd4916f63 Add a new GetThreadOriginExtendedBacktrace method to the
SystemRuntime and SBThread classes.
<rdar://problem/15314369> 

llvm-svn: 194111
2013-11-06 00:04:44 +00:00
Jason Molenda b57e4a1bc6 Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that.  As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended.  Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.

llvm-svn: 193983
2013-11-04 09:33:30 +00:00
Jason Molenda f23bf7432c 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
2013-11-02 02:23:02 +00:00
Jason Molenda 4fdb5863b9 Expose the Thread::GetQueueID() method through the SBThread API, similar to
the existing SBThread::GetQueueName() method.

llvm-svn: 193132
2013-10-21 23:52:54 +00:00
Richard Mitton f86248d9ba Added a 'jump' command, similar to GDBs.
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.

Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)

llvm-svn: 190572
2013-09-12 02:20:34 +00:00
Jim Ingham 4d56e9c1cb This commit does two things. One, it converts the return value of the QueueThreadPlanXXX
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP".  That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further.  If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.

<rdar://problem/14043602>

llvm-svn: 186618
2013-07-18 21:48:26 +00:00
Andrew Kaylor a75418dbd6 Adding new Python API function to check for stopped threads.
llvm-svn: 179577
2013-04-15 23:33:53 +00:00
Greg Clayton 5160ce5c72 <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
2013-03-27 23:08:40 +00:00
Enrico Granata 0a2df227fc the log entry for SBThread::GetProcess() would not include the pointer to the process because we were using the value of the (otherwise unused) process_sp - instead of fetching the SP from sb_process
llvm-svn: 176231
2013-02-28 02:18:49 +00:00
Andrew Kaylor f85defaea5 Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.
llvm-svn: 170800
2012-12-20 23:08:03 +00:00
Jim Ingham c627682ef7 Fixed a few bugs in the "step in" thread plan logic.
Added a "step-in-target" flag to "thread step-in" so if you have something like:

Process 28464 stopped
* thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1
    frame #0: 0x0000000100000e08 a.out`main at main.c:62
   61         
-> 62         int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint.
   63             

and you want to get into "complex" skipping a, b and c, you can do:

(lldb) step -t complex
Process 28464 stopped
* thread #1: tid = 0x1c03, function: complex , stop reason = step in
    frame #0: 0x0000000100000d0d a.out`complex at main.c:44
   41     
   42     int complex (int first, int second, int third)
   43     {
-> 44         return first + second + third;  // Step in targetting complex should stop here
   45     }
   46         
   47     int main (int argc, char const *argv[])

llvm-svn: 170008
2012-12-12 19:58:40 +00:00
Daniel Malea 93a64300f8 Fix Linux build warnings due to redefinition of macros:
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Patch by Matt Kopec!

llvm-svn: 169341
2012-12-05 00:20:57 +00:00
Greg Clayton 90ba81150e <rdar://problem/12649160>
Added the ability to debug through your process exec'ing itself to the same architecture.

llvm-svn: 169340
2012-12-05 00:16:59 +00:00
Daniel Malea d01b2953fa 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
2012-11-29 21:49:15 +00:00
Jim Ingham 4f465cff8a Change the Thread constructor over to take a Process& rather than a ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame 
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.

<rdar://problem/12383087>

llvm-svn: 165640
2012-10-10 18:32:14 +00:00
Greg Clayton 97d5cf05eb <rdar://problem/9959501>
More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running.

llvm-svn: 164584
2012-09-25 02:40:06 +00:00
Jim Ingham 6fe2dc79b7 Remove a duplicate frame_sp local that was shadowing the one we copied the incoming SBFrame into.
<rdar://problem/12304255>

llvm-svn: 163943
2012-09-14 22:16:10 +00:00
Jim Ingham 94b092461d SBThread::StepOut and SBThread::StepOutOfFrame should both run all threads.
llvm-svn: 163938
2012-09-14 21:07:14 +00:00
Jim Ingham c02e334422 SBThread::StepOverUntil should run all threads. It is running to breakpoints, so running one thread is likely to cause the target to stall.
llvm-svn: 163924
2012-09-14 18:57:14 +00:00