| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 201026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
|
|
|
|
|
|
| |
UnwindAssemblySP type.
llvm-svn: 200725
|
|
|
|
| |
llvm-svn: 200565
|
|
|
|
|
|
|
|
|
|
|
|
| |
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
|
|
|
|
|
|
| |
in the step-avoid-libraries list.
llvm-svn: 199944
|
|
|
|
|
|
| |
setting.
llvm-svn: 199943
|
|
|
|
|
|
|
|
|
|
|
| |
This rename was suggested by gclayton as a way to silence gcc
warnings; the warning is emitted when there is an overloaded function
in a base class (Platform) for which a derived class redefines one of
the overloads but not the other (because doing so hides the other
overload from users of the derived class). By giving the two methods
different names, the situation is avoided.
llvm-svn: 199504
|
|
|
|
| |
llvm-svn: 199503
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we would return
control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
|
|
|
|
| |
llvm-svn: 199289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
evaluator to handle Indirect
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
|
|
|
|
|
|
|
|
|
|
| |
parameter is redundant as this information is already provided by the ProcessAttachInfo parameter.
CC: lldb-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2463
llvm-svn: 197923
|
|
|
|
|
|
| |
<rdar://problem/15694319>
llvm-svn: 197631
|
|
|
|
|
|
| |
Fixed a crasher that would only occur if Xcode attaches to a remote process first, then launches.
llvm-svn: 197546
|
|
|
|
| |
llvm-svn: 197541
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While investigating test suite failures when running the test suite remotely, I noticed we had 3 copies of code that launched a process:
1 - in "process launch" command
2 - SBTarget::Launch() with args
3 - SBTarget::Launch() with SBLaunchInfo
"process launch" was launching through the platform if it was supported (this is needed for remote debugging) and the 2 and 3 were not.
Now all code is in one place.
llvm-svn: 197247
|
|
|
|
|
|
|
|
|
| |
libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the
documentation and testing of these but the overall API is settling down so it's
a good time to check it in.
<rdar://problem/15600370>
llvm-svn: 197190
|
|
|
|
| |
llvm-svn: 196956
|
|
|
|
|
|
| |
<rdar://problem/14183288>
llvm-svn: 196949
|
|
|
|
|
|
|
|
|
|
|
| |
should say
it succeeded, since the plan that was using it can figure out what to do from there.
It should only say it failed if it truely went off into the weeds.
<rdar://problem/15597807>
llvm-svn: 196631
|
|
|
|
|
|
|
|
| |
up in crash logs.
<rdar://problem/11549320>
llvm-svn: 196613
|
|
|
|
| |
llvm-svn: 196566
|
|
|
|
|
|
|
|
|
|
| |
symoblicate an address based on a point in time
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
|
|
|
|
|
|
|
|
|
|
| |
lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used.
Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number.
Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings.
llvm-svn: 196141
|
|
|
|
|
|
| |
Added _WIN32 guards to new platform features. Using correct SetErrorStringWithFormat within Host when LLDB_DISABLE_POSIX is defined. Also fixed an if defined block.
llvm-svn: 195766
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Jim Ingham's email:
It does look like ThreadPlanStepInRange test is some kind of thinko.
In practice, in this case it is probably safe to run only one thread
when doing the "step through" since that generally involved running
from a shared library stub to its target. That could deadlock if the
dynamic loader has to fix up the symbol, and another thread is in the
middle of doing that. But that doesn't seem to be very common, or at
least the code is clearly wrong but I haven't had any reports of this
causing deadlocks...
llvm-svn: 195657
|
|
|
|
|
|
|
|
| |
unwinder when StackFrameList::GetFramesUpTo() is called.
Mainly patched to stop LLDB from crashing. This can easily happen if you debug to a remote gdbserver that doesn't have any dynamic register info and you don't have a target definition file specified.
llvm-svn: 195499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
|
|
|
|
|
|
|
| |
natural stop id is updated.
<rdar://problem/15496603>
llvm-svn: 195177
|
|
|
|
|
|
|
|
|
|
| |
threads.
Take a stab at fixing the too-soon freeing of the extended
backtrace thread list in Process.
<rdar://problem/15496603>
llvm-svn: 195104
|
|
|
|
|
|
|
|
| |
do anything right now. Add a few new methods to the Thread base
class which HistoryThread needs. I think I updated all the
CMakeLists files correctly for the new plugin.
llvm-svn: 194756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".
"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.
All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.
Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction.
Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).
Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.
llvm-svn: 194621
|
|
|
|
|
|
|
| |
SBThread::GetExtendedBacktraceThread to make it more clear what is
being returned.
llvm-svn: 194531
|
|
|
|
|
|
| |
In order to help track down llvm.org/pr17226.
llvm-svn: 194487
|
|
|
|
| |
llvm-svn: 194455
|
|
|
|
|
|
|
|
| |
something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068>
llvm-svn: 194367
|
|
|
|
|
|
| |
There were 6 on darwin. All of these were related to the recent changes for exec.
llvm-svn: 194298
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.
Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.
llvm-svn: 194232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
|
|
|
|
|
|
|
| |
bit from the method names.
<rdar://problem/15314369>
llvm-svn: 194122
|
|
|
|
|
|
|
| |
SystemRuntime and SBThread classes.
<rdar://problem/15314369>
llvm-svn: 194111
|
|
|
|
|
|
|
|
| |
Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin.
The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information.
llvm-svn: 194106
|
|
|
|
|
|
|
| |
SystemRuntime class.
<rdar://problem/15314369>
llvm-svn: 194045
|
|
|
|
|
|
|
| |
class, not any actual plugin implementation yet.
<rdar://problem/15314068>
llvm-svn: 194044
|
|
|
|
|
|
|
|
| |
Instead of looking up registers by name, we use the generic ID when we can.
Also added code that creates an extra frame when running expressions by pushing the current PC and FP and then hooking up the FP backchain. This code is "#if 0" out for now until we can pair it with unwinder fixes.
llvm-svn: 194035
|
|
|
|
|
|
|
|
| |
Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments.
The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen.
llvm-svn: 194009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at some point in the past. We may have nothing more than a pc value
for this type of stack frame -- hopefully we'll have a pc and a
stop_id so we can track module loads and unloads over time and
symbolicate the pc at the correct point in time.
Also add a flag to indicate if the CFA for the frame is available
(a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an
overall setting to indicate whether this is a history stack frame
or not. A history stack frame may not have a CFA, it may not have
a register context, it may not have variables, it may not have a
frame pointer or a stack pointer.
<rdar://problem/15314068>
llvm-svn: 193987
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|