summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
* <rdar://problem/12350715>Jason Molenda2013-01-191-0/+13
| | | | | | | | | | | | | | | | Modify UnwindLLDB::SearchForSavedLocationForRegister so if the register save locations for a register mid-stack is in another register (or in the same register, indicating the reg wasn't modified in this frame), don't return that as a found location. Keep iterating down the array of frames until a concrete location/value for the register is found, or until we get to frame 0 where the reg value can be used as-is. If lldb was trying to backtrace a program that blew out its stack via recursion and the unwind instructions had some kind of this-reg-is-saved-in-that-reg instruction, lldb would revert to doing a recursive search for a concrete value and blow out its own stack. llvm-svn: 172887
* <rdar://problem/13010007>Greg Clayton2013-01-182-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method: class OperatingSystemPlugin: def create_thread(self, tid, context): # Return a dictionary for a new thread to create it on demand This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used. Cleaned up the code in PythonDataObjects.cpp/h: - renamed all classes that started with PythonData* to be Python*. - renamed PythonArray to PythonList. Cleaned up the code to use inheritance where - Centralized the code that does ref counting in the PythonObject class to a single function. - Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object. - Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form: - PyObject * - const PythonObject & - const lldb::ScriptInterpreterObjectSP & Cleaned up code in ScriptInterpreterPython: - Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time. - Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized. llvm-svn: 172873
* <rdar://problem/12976277>Han Ming Ong2013-01-183-5/+133
| | | | | | Swap in index ids for thread ids in GDBRemoteCommunicationClient. Besides dealing with the async logic, I have to take care of the situation when the inferior paused as well. llvm-svn: 172869
* Separated the "expr --unwind-on-error" behavior into two parts, actual ↵Jim Ingham2013-01-151-6/+12
| | | | | | | | | | | | | | | | errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
* <rdar://problem/12976225>Han Ming Ong2013-01-081-2/+16
| | | | | | Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
* <rdar://problem/12586010>Greg Clayton2013-01-081-1/+4
| | | | | | | | Python OS plug-ins now fetch thread registers lazily. Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach". llvm-svn: 171901
* Fixed comment typo.Greg Clayton2013-01-081-1/+1
| | | | llvm-svn: 171900
* Add initial support to trace spawned threads in a process on Linux.Matt Kopec2013-01-089-21/+134
| | | | llvm-svn: 171864
* Implement -w flag to process launch (allow launching inferior process in ↵Daniel Malea2013-01-085-9/+53
| | | | | | | | different working directory) on Linux/FreeBSD - fixes test case TestProcessLaunch llvm-svn: 171854
* Fix TestSendSignals.py on Linux. The wrong stop reason was being set when ↵Matt Kopec2013-01-081-2/+1
| | | | | | stopping for a received signal. llvm-svn: 171819
* Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.Andrew Kaylor2012-12-201-3/+3
| | | | llvm-svn: 170800
* <rdar://problem/11961650> Jason Molenda2012-12-193-4/+139
| | | | | | | | | | | | | | | | | Update the debugserver "qProcessInfo" implementation to return the cpu type, cpu subtype, OS and vendor information just like qHostInfo does so lldb can create an ArchSpec based on the returned values. Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin to GetHostArchitecture. If the qProcessInfo packet is supported, GetProcessArchitecture will return the cpu type / subtype of the process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac system. Have ProcessGDBRemote set the Target's architecture based on the GetProcessArchitecture when we've completed an attach/launch/connect. llvm-svn: 170491
* Allow reading registers by thread ID in ProcessMonitor (Linux implementation)Daniel Malea2012-12-186-60/+86
| | | | | | | | - make FreeBSD ProcessMonitor API thread-ready Patch by Matt Kopec! llvm-svn: 170445
* Adding events when watchpoints are set or changed.Jim Ingham2012-12-184-11/+12
| | | | | | <rdar://problem/11597849> llvm-svn: 170400
* Avoid possible overflow when reading inferior memory (and logging is enabled)Daniel Malea2012-12-141-4/+8
| | | | | | Patch by Matt Kopec! llvm-svn: 170242
* Change crash handling to use eStateStopped rather than eStateCrashed.Andrew Kaylor2012-12-141-1/+2
| | | | llvm-svn: 170224
* Fix a few more clang (3.2) warnings on Linux:Daniel Malea2012-12-073-13/+17
| | | | | | | | | | | | | | | | | - remove unused members - add NO_PEDANTIC to selected Makefiles - fix return values (removed NULL as needed) - disable warning about four-char-constants - remove unneeded const from operator*() declaration - add missing lambda function return types - fix printf() with no format string - change sizeof to use a type name instead of variable name - fix Linux ProcessMonitor.cpp to be 32/64 bit friendly - disable warnings emitted by swig-generated C++ code Patch by Matt Kopec! llvm-svn: 169645
* More Linux warnings fixes (remove default labels as needed):Daniel Malea2012-12-074-15/+0
| | | | | | | | - as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations Patch by Matt Kopec! llvm-svn: 169633
* <rdar://problem/12820334>Greg Clayton2012-12-061-2/+2
| | | | | | | | | | | | | I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-055-0/+10
| | | | | | | | | - 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
* <rdar://problem/12649160>Greg Clayton2012-12-053-0/+48
| | | | | | Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
* Read full 64 bits of kernel address when locating aJason Molenda2012-12-011-1/+1
| | | | | | | 64-bit kernel in ProcessGDBRemote. <rdar://problem/12657369> llvm-svn: 169080
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-2920-111/+111
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* <rdar://problem/12723044> For 'process plugin packet send…', we just send ↵Han Ming Ong2012-11-261-25/+13
| | | | | | | | it async by default There is no good reason not to use async. llvm-svn: 168606
* Fix Linux bug that leaves lldb in invalid state after expression evaluation ↵Daniel Malea2012-11-234-16/+35
| | | | | | | | | | | | times out. - Handle EINVAL return code from ptrace(GETSIGINFO, ...): not an error, but 'group-stop' state on Linux - propagate SIGSTOP to inferior in above case - this commit resolves the failure in expression_command/timeout testcase Thanks to Sean Callanan & Matt Kopec for helping debug this problem llvm-svn: 168523
* Remove call to StopMonitor() from ProcessMonitor::Detach()Daniel Malea2012-11-221-2/+2
| | | | | | | | | - StopMonitor() is called anyways from ProcessMonitor destructor later - resolves hang in TestEvents.py Patch by Matt Kopec! llvm-svn: 168503
* <rdar://problem/12720514> Sub-TLF: Provide service to profile the inferiorHan Ming Ong2012-11-171-0/+10
| | | | | | This allows client to query profiling states on the inferior. llvm-svn: 168228
* Change RegisterContextLLDB's unwind logging to report which stack frameJason Molenda2012-11-161-4/+12
| | | | | | | finally was able to restore a register, instead of just reporting the frames that couldn't supply the reg. llvm-svn: 168139
* A change in how we search for saved register values unintentionallyJason Molenda2012-11-164-22/+35
| | | | | | | | | allowed volatile registers to be returned up the stack. That leads to unexpected/incorrect values provided to the user and we need to avoid that. <rdar://problem/12714247> llvm-svn: 168123
* Add support for libdispatch version 4 structure layout for findingJason Molenda2012-11-101-7/+24
| | | | | | | | | | GCD queue names of threads to ProcessGDBRemote::GetDispatchQueueNameForThread() May need tweaking once this version is rolled out but visual inspection looks fine. <rdar://problem/12333100> llvm-svn: 167667
* Remove a debugging printf that was left in the code.Greg Clayton2012-11-091-1/+0
| | | | llvm-svn: 167637
* Removed use of non-standard escape character '\%'Filipe Cabecinhas2012-11-091-1/+1
| | | | llvm-svn: 167636
* There seems to be some odd corner case where we shut down the ↵Jim Ingham2012-11-012-12/+60
| | | | | | | | ProcessGDBRemote, but we haven't managed to shut down the async thread. That causes the ProcessGDBRemote::AsyncThread to crash when it wakes up. So I changed StartAsyncThread and StopAsyncThread to be callable multiple times (only the first one does anything) so that we can just shut it down unequivocally in the ProcessGDBRemote destructor. <rdar://problem/12602981> llvm-svn: 167197
* <rdar://problem/12602978>Greg Clayton2012-10-303-88/+31
| | | | | | RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions. llvm-svn: 167066
* Patch from Matt Kopec <matt.kopec@intel.com> to handle stepping into ↵Jim Ingham2012-10-301-2/+5
| | | | | | multiply-nested inlined code. llvm-svn: 167028
* If we got what looks like a single step exception but we weren't single ↵Jim Ingham2012-10-272-5/+11
| | | | | | | | stepping then just report the raw exception. llvm-svn: 166859
* Add a new capability to RegisterContextLLDB: To recognize when theJason Molenda2012-10-264-339/+327
| | | | | | | | | | | | | | | | | | | | | | | | | Full UnwindPlan is trying to do an impossible unwind; in that case invalidate the Full UnwindPlan and replace it with the architecture default unwind plan. This is a scenario that happens occasionally with arm unwinds in particular; the instruction analysis based full unwindplan can mis-parse the functions and the stack walk stops prematurely. Now we can do a simpleminded frame-chain walk to find the caller frame and continue the unwind. It's not ideal but given the complicated nature of analyzing the arm functions, and the lack of eh_frame information on iOS, it is a distinct improvement and fixes some long-standing problems with the unwinder on that platform. This is fixing <rdar://problem/12091421>. I may re-use this invalidate feature in the future if I can identify other cases where the full unwindplan's unwind information is clearly incorrect. This checkin also includes some cleanup for the volatile register definition in the arm ABI plugin for <rdar://problem/10652166> although work remains to be done for that bug. llvm-svn: 166757
* Allow operating system plug-ins to specify the address for registers so we ↵Greg Clayton2012-10-252-6/+10
| | | | | | don't have to create data up front. llvm-svn: 166701
* Identify a kdp session that is connecting to an EFI monitor,Jason Molenda2012-10-253-3/+23
| | | | | | | use a DynamicLoaderStatic dynamic loader for the session instead of a kernel or user dynamic loader. llvm-svn: 166652
* Patch from Ashok Thirumurthi that enabled FPU registers for POSIX x86_64.Greg Clayton2012-10-241-4/+59
| | | | llvm-svn: 166604
* <rdar://problem/12491387>Greg Clayton2012-10-195-6/+254
| | | | | | | | | | Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header. An example of sending a read register packet for the GPR on x86_64: (lldb) process plugin packet send --command 0x07 --payload 0100000004000000 llvm-svn: 166346
* Change CommunicationKDP::SendRequestWriteMemory to append data as binaryJason Molenda2012-10-191-1/+1
| | | | | | instead of asciified bytes. <rdar://problem/12522978> llvm-svn: 166258
* Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham2012-10-161-4/+4
| | | | | | | | | | "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
* Patch from Matt Kopec:Greg Clayton2012-10-162-36/+30
| | | | | | This patch fixes an issue where if lldb fails to attach to a process (ie. invalid pid) on Linux, the process monitor thread gets stuck waiting for a signal from the attach thread, which never comes due to not being signaled. It also implements StopOpThread which is used for both attach/launch cases as I'm not aware of any special handling needed for the attach case. Also, propagate 'Error' from the Detach function instead of using a bool. llvm-svn: 166055
* Add a new ABI plugin method which specifies whether the architectureJason Molenda2012-10-161-1/+1
| | | | | | | | | | | | | | | must push something on the stack for a function call or not. In x86, the stack pointer is decremented when the caller's pc is saved on the stack. In arm, the stack pointer and frame pointer don't necessarily have to change for a function call, although most functions need to use some stack space during their execution. Use this information in the RegisterContextLLDB to detect invalid unwind scenarios more accurately. <rdar://problem/12348574> llvm-svn: 166005
* Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two ↵Jim Ingham2012-10-164-0/+12
| | | | | | | | breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
* Added "process plugin packet send" and "process plugin packet history" for ↵Greg Clayton2012-10-151-8/+106
| | | | | | GDB remote. "process plugin packet send" will send a packet and receive a response. "process plugin packet history" will dump the packet history buffer. llvm-svn: 165991
* Make sure we always use lldb::tid_t for thread IDs so we don't truncate a 64 ↵Greg Clayton2012-10-132-3/+3
| | | | | | bit thread ID. llvm-svn: 165862
* <rdar://problem/12491387>Greg Clayton2012-10-132-3/+60
| | | | | | | | | | | I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override: virtual CommandObject * GetPluginCommandObject(); This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented! llvm-svn: 165861
* <rdar://problem/12489931>Greg Clayton2012-10-121-1/+1
| | | | | | Memory write wasn't working (assert was firing) when writing memory. llvm-svn: 165848
OpenPOWER on IntegriCloud