| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 207945
|
|
|
|
|
|
|
|
|
| |
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
|
|
|
|
|
|
|
|
|
|
|
|
| |
- CTRL+C wasn't clearing the command in lldb
- CTRL+C doesn't work in python macros in lldb
- Ctrl+C no longer interrupts the running process that you attach to
<rdar://problem/15949205>
<rdar://problem/16778652>
<rdar://problem/16774411>
llvm-svn: 207816
|
|
|
|
|
|
| |
/bin/sh or /usr/bin/arch can crash the process due to security measures. Now we correctly report when a process exited in the process of launching so we can show the reason why it crashed instead of just showing “initial process state wasn't stopped: exited”.
llvm-svn: 207700
|
|
|
|
| |
llvm-svn: 207564
|
|
|
|
|
|
|
|
|
| |
evaluation AFTER the
successful resume for that part. This will make the timeouts more stable when lldb is running
in a busy program.
llvm-svn: 206835
|
|
|
|
|
|
|
|
|
|
| |
(only for STDIN) pseudo terminal usage in the debugging process.
Here is the fix resolving this issue.
Patch from Alexey Ushakov.
llvm-svn: 206476
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
headers
on Mac OS X (in particular mach/machine.h).
<rdar://problem/16494607>
llvm-svn: 205480
|
|
|
|
|
|
|
|
| |
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
|
|
|
|
|
|
|
| |
This should fix the seemingly-random failures observed on the FreeBSD
buildbot.
llvm-svn: 205241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source info:
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
|
|
|
|
|
|
| |
No functionnal change.
llvm-svn: 204545
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
|
|
|
|
|
|
| |
code.
llvm-svn: 204087
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
(serial or concurrent).
<rdar://problem/7964505>
llvm-svn: 203748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that it is useful not only
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also
the behavior of step-in/step-out and step-over when they step out of the frame they started in.
I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame
into a frame with no debug information will continue stepping out till it arrives at a frame that does
have debug information. This is useful when you are debugging callback based code where the callbacks
are separated from the code that initiated them by some library glue you don't care about, among other
things.
llvm-svn: 203747
|
|
|
|
|
|
|
| |
This allows to use some code for mingw which was previously only
used for MSVC.
llvm-svn: 203651
|
|
|
|
|
|
|
|
|
| |
Seed the QueueItem objects with the item_refs and addresses when they are fetched
in one batch. If additional information is needed from the QueueItem, fetch it
lazily one pending item per function call.
<rdar://problem/16270007>, <rdar://problem/16032150>
llvm-svn: 203449
|
|
|
|
|
|
|
|
|
|
|
| |
changing the data it returns; this change accepts either the old format or
the new format. It doesn't yet benefit from the new format's additions -
but I need to get this checked in so we aren't rev-locked.
Also add a missing .i entry for SBQueue::GetNumRunningItems() missing from
the last checkin.
<rdar://problem/16272115>
llvm-svn: 203421
|
|
|
|
| |
llvm-svn: 203349
|
|
|
|
|
|
|
|
|
|
| |
Thread) calls
or the lower levels of the Process won't be able to restart.
<rdar://problem/16244835>
llvm-svn: 203233
|
|
|
|
|
|
| |
address subplan.
llvm-svn: 203231
|
|
|
|
|
|
|
|
|
|
|
| |
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
|
|
|
|
|
|
| |
crashes when lldb follows through exec's...
llvm-svn: 203068
|
|
|
|
|
|
|
|
| |
the header files were in "include/lldb/Target".
Also enabled the ELF Core file support in all builds since the header files have been properly separated from ProcessMonitor.
llvm-svn: 203035
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202723
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
MacOSX for "localhost".
Changed all "localhost" to "127.0.0.1" to prevent potentially long name lookups.
<rdar://problem/16154630>
llvm-svn: 202424
|
|
|
|
| |
llvm-svn: 202423
|
|
|
|
|
|
|
|
|
| |
parameter.
This change converts points to clang::ExternalASTSource from llvm::OwningPtr<> to
llvm::IntrusiveRefCntPtr<>.
llvm-svn: 202411
|
|
|
|
|
|
|
|
| |
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: 201665
|
|
|
|
|
|
|
|
|
|
|
|
| |
specify a list of functions which should be treated as trap handlers.
This will be primarily useful to people working in non-user-level
process debugging - kernels and other standalone environments.
For most people, the trap handler functions provided by the Platform
plugin will be sufficient.
<rdar://problem/15835846>, <rdar://problem/15982682>
llvm-svn: 201386
|
|
|
|
|
|
|
|
|
| |
operating system plugins, and other async python usage.
<rdar://problem/16054348>
<rdar://problem/16040833>
llvm-svn: 201372
|
|
|
|
|
|
|
|
| |
add a new pure virtual CalculateTrapHandlerSymbolNames() that Platform
subclasses must implement which fills in the function name list with any
trap handlers that are expected on that platform.
llvm-svn: 201364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
|