| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 206351
|
|
|
|
|
|
|
|
|
|
| |
but by the time we go to halt, it has already stopped by hitting the
function end breakpoint. That wasn't being shown to the threads so the
Function call thread plan didn't know its job was done.
<rdar://problem/16515785>
llvm-svn: 205803
|
|
|
|
|
|
|
| |
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
|
|
|
|
| |
llvm-svn: 205497
|
|
|
|
|
|
|
| |
This should fix the seemingly-random failures observed on the FreeBSD
buildbot.
llvm-svn: 205241
|
|
|
|
|
|
|
|
| |
for expression evaluations that try one and then all threads.
<rdar://problem/15598528>
llvm-svn: 205060
|
|
|
|
|
|
| |
m_thread_list.DiscardThreadPlans() into base Process::Destroy() instead of in subclass DoDestroy() methods.
llvm-svn: 204752
|
|
|
|
|
|
| |
as suggested by Jim Ingham. Make JITLoader instances use this to probe only new modules for relevant JIT symbols. Also re-enable the JITLoader hooks in Process.
llvm-svn: 203774
|
|
|
|
|
|
|
| |
This allows to use some code for mingw which was previously only
used for MSVC.
llvm-svn: 203651
|
|
|
|
|
|
|
|
|
|
| |
Thread) calls
or the lower levels of the Process won't be able to restart.
<rdar://problem/16244835>
llvm-svn: 203233
|
|
|
|
|
|
| |
crashes when lldb follows through exec's...
llvm-svn: 203068
|
|
|
|
|
|
| |
written with Keno Fischer.
llvm-svn: 202956
|
|
|
|
|
|
|
|
| |
style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed.
If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64.
llvm-svn: 202738
|
|
|
|
|
|
|
|
| |
I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion.
<rdar://problem/16111293>
llvm-svn: 202525
|
|
|
|
|
|
|
|
|
| |
and make it work in RunThreadPlan.
Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is
in the EvaluateExpressionOptions the plan was passed when created it won't work correctly.
llvm-svn: 202464
|
|
|
|
|
|
|
|
| |
writing to the pipe that was used for cancel.
We now write a 'q' to indicate to exit the IOHandlerProcessSTDIO::Run(), and a 'i' to interrupt the process. This should make this code safer to use in a signal handler function.
llvm-svn: 202311
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't actually Halt in the Interrupt handler for the Process, just
send an AsyncInterrupt. That's actually not async-signal-clean, but
it is a lot safer than Halt...
The underlying problem is actually a nested pthread_cond_wait from the
signal handler. Note frames 4, 13, 18 in the backtrace of the aborting
path below.
frame #1: 0x000000080715fff9 libc.so.7`abort + 73 at abort.c:65
frame #2: 0x0000000805d20fda libthr.so.3`_thread_exit(fname=<unavailable>, lineno=<unavailable>, msg=<unavailable>) + 58 at thr_exit.c:182
frame #3: 0x0000000805d1fdc8 libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 936 at thr_cond.c:223
frame #4: 0x0000000805d1fd5b libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=<unavailable>, cancel=<unavailable>) + 827 at thr_cond.c:311
frame #5: 0x00000008013450b5 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 117
frame #6: 0x00000008013411e8 liblldb.so.3.5`lldb_private::Predicate<bool>::WaitForValueEqualTo(bool, lldb_private::TimeValue const*, bool*) + 200
frame #7: 0x00000008013eb34c liblldb.so.3.5`lldb_private::Listener::WaitForEventsInternal(lldb_private::TimeValue const*, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::__1::shared_ptr<lldb_private::Event>&) + 876
frame #8: 0x00000008013eb751 liblldb.so.3.5`lldb_private::Listener::WaitForEvent(lldb_private::TimeValue const*, std::__1::shared_ptr<lldb_private::Event>&) + 81
frame #9: 0x00000008017c5bcf liblldb.so.3.5`lldb_private::Process::Halt(bool) + 783
frame #10: 0x00000008017def3a liblldb.so.3.5`IOHandlerProcessSTDIO::Interrupt() + 74
frame #11: 0x00000008013823d3 liblldb.so.3.5`lldb_private::Debugger::DispatchInputInterrupt() + 115
frame #12: 0x00000008011d69c5 liblldb.so.3.5`lldb::SBDebugger::DispatchInputInterrupt() + 69
frame #13: 0x000000000040b254 lldb`sigint_handler(int) + 68
frame #14: 0x0000000805d1b3da libthr.so.3`handle_signal(actp=<unavailable>, sig=<unavailable>, info=<unavailable>, ucp=<unavailable>) + 234 at thr_sig.c:240
frame #15: 0x0000000805d1afc2 libthr.so.3`thr_sighandler(sig=<unavailable>, info=<unavailable>, _ucp=<unavailable>) + 306 at thr_sig.c:183
frame #16: 0x00007ffffffff003
frame #17: 0x0000000805d1fc7e libthr.so.3`cond_wait_common [inlined] cond_wait_user(mp=<unavailable>, abstime=<unavailable>, cancel=1) + 239 at thr_cond.c:255
frame #18: 0x0000000805d1fb8f libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) + 367 at thr_cond.c:311
frame #19: 0x00000008013450d2 liblldb.so.3.5`lldb_private::Condition::Wait(lldb_private::Mutex&, lldb_private::TimeValue const*, bool*) + 146
llvm-svn: 202154
|
|
|
|
|
|
| |
process again.
llvm-svn: 202086
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
class, not any actual plugin implementation yet.
<rdar://problem/15314068>
llvm-svn: 194044
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 193488
|
|
|
|
|
|
| |
macros.
llvm-svn: 193260
|
|
|
|
| |
llvm-svn: 193159
|
|
|
|
|
|
|
|
| |
Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.
Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.
llvm-svn: 192491
|
|
|
|
|
|
|
|
|
| |
already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped
llvm-svn: 192301
|
|
|
|
|
|
| |
of the function.)
llvm-svn: 191476
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that /bin/sh re-exec's itself to /bin/bash, so it needs one more resume when you
are using it as the shell than /bin/bash did or you will stop at the start of your
program, rather than running it.
So I added a Platform API to get the number of resumes needed when launching with
a particular shell, and set the right values for Mac OS X.
<rdar://problem/14935282>
llvm-svn: 190381
|
|
|
|
| |
llvm-svn: 190063
|
|
|
|
|
|
|
|
| |
/bin/sh is more portable, and all systems with /bin/bash are expected to
have /bin/sh as well, even if only a link to bash.
Review: http://llvm-reviews.chandlerc.com/D1576
llvm-svn: 189879
|
|
|
|
| |
llvm-svn: 189355
|
|
|
|
| |
llvm-svn: 189317
|
|
|
|
|
|
| |
portability.
llvm-svn: 189107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and StackFrameList mutex)
- this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex
Situation where deadlock could occur (without this fix):
Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex.
Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex)
In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied.
llvm-svn: 187522
|