| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
Added the ability to debug through your process exec'ing itself to the same architecture.
llvm-svn: 169340
|
|
|
|
|
|
|
|
| |
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
|
|
|
|
|
|
|
|
|
| |
soon, causing recursive entry into the
breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct.
<rdar://problem/12501259>
llvm-svn: 168634
|
|
|
|
| |
llvm-svn: 168343
|
|
|
|
|
|
|
| |
Thread::ResetFrameZeroRegisters() clear the UnwindLLDB object when
resetting the thread's register state.
llvm-svn: 167910
|
|
|
|
|
|
|
|
| |
I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad.
To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen.
llvm-svn: 166964
|
|
|
|
|
|
|
|
| |
breakpoints were set on consecutive addresses, the continue from the
first breakpoint would skip the second.
llvm-svn: 166000
|
|
|
|
| |
llvm-svn: 165808
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
when we have a StopInfo object.
llvm-svn: 164825
|
|
|
|
|
|
|
|
|
|
| |
i386. Also returns
floats & doubles on x86_64.
<rdar://problem/8356523>
llvm-svn: 164741
|
|
|
|
|
|
| |
More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running.
llvm-svn: 164584
|
|
|
|
|
|
| |
thread return command.
llvm-svn: 163867
|
|
|
|
| |
llvm-svn: 163670
|
|
|
|
| |
llvm-svn: 163576
|
|
|
|
| |
llvm-svn: 163433
|
|
|
|
|
|
|
|
| |
callback gets a chance to run.
If the stopped event comes in with the Restarted bit set, don't try to hand that to the plans, but just return ShouldStop = false. There's nothing useful the plans can do, since the target is already running.
llvm-svn: 163244
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from an ExecutionContextRef,
particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting
the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the
context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another
command Destroy's the Thread you've just gotten.
Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects.
Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing
that scope has been destroyed.
Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value.
<rdar://problem/11995490>
llvm-svn: 162401
|
|
|
|
| |
llvm-svn: 162376
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads
Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".
llvm-svn: 162366
|
|
|
|
|
|
| |
return bool.
llvm-svn: 161719
|
|
|
|
|
|
|
|
|
| |
and instead made us use implicit casts to bool.
This generated a warning in C++11.
<rdar://problem/11930775>
llvm-svn: 161559
|
|
|
|
|
|
|
|
| |
a continue if the unwinder didn't unwind correctly.
<rdar://problem/11989668>
llvm-svn: 161086
|
|
|
|
|
|
| |
The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them.
llvm-svn: 160071
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/11455913>
"target symbol add" should flush the cached frames
"register write" should flush the thread state in case registers modifications change stack
llvm-svn: 157042
|
|
|
|
| |
llvm-svn: 156668
|
|
|
|
|
|
|
| |
Also changed the defaults for SBThread::Step* to not delete extant plans.
Also added some test cases to test more complex stepping scenarios.
llvm-svn: 156667
|
|
|
|
|
|
|
|
| |
not AND unwind on error.
rdar://problem/11419156
llvm-svn: 156627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
propagate the error back to
the controlling plans so that they don't lose control.
Also change "ThreadPlanStepThrough" to take the return StackID for its backstop breakpoint as an argument
to the constructor rather than having it try to figure it out itself, since it might get it wrong whereas
the caller always knows where it is coming from.
rdar://problem/11402287
llvm-svn: 156529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
user-initiated plans
should be MasterPlans that want to stay on the plan stack. So make all plans NOT
MasterPlans by default and then have the SB API's and the CommandObjectThread step
commands set this explicitly.
Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded
on the stack, we can remove them. This is done by adding an IsPlanStale method to the
thread plans, and if the plan can know that it is no longer relevant, it returns true,
and the plan and its sub-plans will get discarded.
llvm-svn: 156101
|
|
|
|
|
|
| |
of a crash or breakpoint. Added the ability for a plan to say it is done but doesn't want to be the reason for the stop.
llvm-svn: 155927
|
|
|
|
|
|
|
|
|
|
|
| |
thread plan logic gets invoked, and if they
ask to continue that should short-circuit the thread plans for that thread. Also add a bit more explanation for
how this machinery is supposed to work.
Also pass eExecutionPolicyOnlyWhenNeeded, not eExecutionPolicyAlways when evaluating the expression for breakpoint
conditions.
llvm-svn: 155236
|
|
|
|
|
|
|
|
|
| |
entry point to contol logic
for the plan stack, so assert here if it gets called with an empty plan stack.
<rdar://problem/11265974>
llvm-svn: 155078
|
|
|
|
|
|
| |
a StopInfoThreadPlan, and that would hold onto members that need to be destroyed while the Full thread is still around.
llvm-svn: 154366
|
|
|
|
|
|
| |
rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such.
llvm-svn: 154351
|
|
|
|
|
|
| |
Fixed an issue with stepping where the stack frame list could get changed out from underneath you when multiple threads start accessing frame info.
llvm-svn: 153627
|
|
|
|
|
|
| |
or QueueName if the ThreadSpec doesn't specify them.
llvm-svn: 152245
|
|
|
|
|
|
|
|
|
| |
needed to
get the frame requested.
<rdar://problem/10943135>
llvm-svn: 151705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 150871
|
|
|
|
|
|
|
|
|
| |
were suspended in the most
recent step, and if they weren't allowed to run, don't ask questions about their state unless explicitly
requested to do so.
llvm-svn: 149443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
frames might go away (the object itself, not the actual logical frame) when
we are single stepping due to the way we currently sometimes end up flushing
frames when stepping in/out/over. They later will come back to life
represented by another object yet they have the same StackID. Now when you get
a lldb::SBFrame object, it will track the frame it is initialized with until
the thread goes away or the StackID no longer exists in the stack for the
thread it was created on. It uses a weak_ptr to both the frame and thread and
also stores the StackID. These three items allow us to determine when the
stack frame object has gone away (the weak_ptr will be NULL) and allows us to
find the correct frame again. In our test suite we had such cases where we
were just getting lucky when something like this happened:
1 - stop at breakpoint
2 - get first frame in thread where we stopped
3 - run an expression that causes the program to JIT and run code
4 - run more expressions on the frame from step 2 which was very very luckily
still around inside a shared pointer, yet, not part of the current
thread (a new stack frame object had appeared with the same stack ID and
depth).
We now avoid all such issues and properly keep up to date, or we start
returning errors when the frame doesn't exist and always responds with
invalid answers.
Also fixed the UserSettingsController (not going to rewrite this just yet)
so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
track when the master controller has already gone away and this allowed me to
pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer
needed.
llvm-svn: 149231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
llvm-svn: 149207
|
|
|
|
|
|
|
|
| |
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.
llvm-svn: 147157
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
print it
as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers. That way this will always
be good.
llvm-svn: 146806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address from
the function it is being asked to step through, so that even if we get the trampoline
target wrong (for instance) we will still not lose control.
The other fix here is to tighten up the handling of the case where the current plan
doesn't explain the stop, but a plan above us does. In that case, if the plan that
does explain the stop says it is done, we need to clean up the plans below it and
continue on with our processing.
llvm-svn: 145740
|
|
|
|
|
|
|
|
|
|
|
| |
process IDs, and thread IDs, but was mainly needed for for the UserID's for
Types so that DWARF with debug map can work flawlessly. With DWARF in .o files
the type ID was the DIE offset in the DWARF for the .o file which is not
unique across all .o files, so now the SymbolFileDWARFDebugMap class will
make the .o file index part (the high 32 bits) of the unique type identifier
so it can uniquely identify the types.
llvm-svn: 142534
|
|
|
|
| |
llvm-svn: 142025
|