summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/MacOSX-Kernel
Commit message (Collapse)AuthorAgeFilesLines
...
* Changed the formerly pure virtual function:Greg Clayton2013-05-093-39/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; } To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function: namespace lldb_private { class Thread { virtual bool CalculateStopInfo() = 0; } } This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings. Also renamed: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopReason(); To: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopInfo(); Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads). llvm-svn: 181501
* Fix the error reporting for ProcessKDP::DoDetach.Jim Ingham2013-05-091-5/+10
| | | | llvm-svn: 181493
* Reinstating r181091 and r181106 with fix for Linux regressions.Andrew Kaylor2013-05-072-17/+20
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-072-20/+17
| | | | | | | | | | the Linux buildbots while we develop a better understanding of how to manage the thread lists in a platform-independant fashion. Reviewed by: Daniel Malea llvm-svn: 181323
* In ProcessKDP, if the remote connection is not EFI,Jason Molenda2013-05-061-2/+5
| | | | | | | | force this to be a DynamicLoaderDarwinKernel debug session even if we didn't get back a load address for the kernel. llvm-svn: 181264
* Change ProcessKDP::UpdateThreadList's call to FindThreadByProtocolIDJason Molenda2013-05-041-1/+1
| | | | | | | to not let it update the thread list or else we'll infinite recurse call back to UpdateThreadList. llvm-svn: 181106
* After recent OperatingsSystem plug-in changes, the lldb_private::Process and ↵Greg Clayton2013-05-042-17/+20
| | | | | | | | | | lldb_private::Thread subclasses were changed and the API was not respected properly. This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list. These changes keep the lldb_private::Process subclasses clean and no changes are required. llvm-svn: 181091
* Recommitting r180831 with trivial fix - remember to return errors if you ↵Jim Ingham2013-05-022-5/+7
| | | | | | compute. llvm-svn: 180898
* <rdar://problem/13700260>Greg Clayton2013-05-012-33/+0
| | | | | | | | | | | | | | <rdar://problem/13723772> Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves. A few things are introduced: - lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread. - Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification. - Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them - Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation. llvm-svn: 180886
* Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.pyDaniel Malea2013-05-012-7/+5
| | | | llvm-svn: 180868
* Added an option to "process detach" to keep the process stopped, if the ↵Jim Ingham2013-04-302-5/+7
| | | | | | | | | | process plugin (or in the case of ProcessGDBRemote the stub we are talking to) know how to do that. rdar://problem/13680832 llvm-svn: 180831
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-1/+1
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-1/+1
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* <rdar://problem/13491977>Greg Clayton2013-04-121-2/+6
| | | | | | | | Made some fixes to the OperatingSystemPython class: - If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread. - Cleaned up all the places where a thread inside a thread was causing problems llvm-svn: 179405
* Fixed the thread list so it correctly updates after the first core thread ↵Greg Clayton2013-04-111-4/+2
| | | | | | exists. llvm-svn: 179326
* <rdar://problem/13516463>Greg Clayton2013-04-022-7/+36
| | | | | | Don't crash when there is no register context for a thread with kernel debugging. The kernel debugging uses the OperatingSystemPlugin that may behave badly when trying to get thread state, so be prepared to have invalid register contexts in threads. llvm-svn: 178574
* Fix the Linux build issues introduced by r178191.Ashok Thirumurthi2013-03-281-1/+1
| | | | | | | | | - All Linux logging channels now use a single global instance of lldb_private::Log, to handle the case of logging during process tear down. - Also removed a single use of LogSP in FreeBSD and fixed a typo in a comment while reading through ProcessKDPLog. Reviewed by Daniel Malea. llvm-svn: 178242
* <rdar://problem/13521159>Greg Clayton2013-03-275-35/+39
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Move m_destroy_in_process to Process (from ProcessKDP) since it is generally ↵Jim Ingham2013-03-012-13/+0
| | | | | | | | | | | | useful, and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since if that does anything that requires the API lock it may deadlock against whoever is running the Process::Destroy. <rdar://problem/13308627> llvm-svn: 176375
* Patch from Andrew Fish to add recognition of some additionalJason Molenda2013-03-012-3/+154
| | | | | | KDP packets. llvm-svn: 176319
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+11
| | | | | | | | | | | | | | - generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
* A little cleanup. {Disable/Enable}Breakpoint actually disables/enables ↵Jim Ingham2013-02-152-4/+4
| | | | | | | | | BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
* <rdar://problem/13064893>Greg Clayton2013-02-142-43/+32
| | | | | | Poor network connections aren't handled well; commands fail instead of retrying. llvm-svn: 175198
* <rdar://problem/13069948>Greg Clayton2013-01-252-13/+13
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* Adding events when watchpoints are set or changed.Jim Ingham2012-12-182-4/+4
| | | | | | <rdar://problem/11597849> llvm-svn: 170400
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-293-16/+16
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* 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
* <rdar://problem/12491387>Greg Clayton2012-10-194-4/+252
| | | | | | | | | | 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
* Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two ↵Jim Ingham2012-10-161-0/+3
| | | | | | | | breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
* <rdar://problem/12489931>Greg Clayton2012-10-121-1/+1
| | | | | | Memory write wasn't working (assert was firing) when writing memory. llvm-svn: 165848
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-103-4/+4
| | | | | | | | | | | | | 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
* Remove a few debug printf's that were left in ProcessKDP.Jason Molenda2012-10-041-5/+0
| | | | llvm-svn: 165192
* The kernel loading code is now isolated in the DynamicLoaderDarwinKernel;Jason Molenda2012-10-032-76/+29
| | | | | | | | | | remove the duplicates of this code in ProcessGDBRemote and ProcessKDP. These two Process plugins will hardcode their DynamicLoader name to be the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked, and return the kernel load address as the ImageInfosAddress. <rdar://problem/12417038> llvm-svn: 165080
* Add support for debugging KASLR kernels via kdp (the kernel beingJason Molenda2012-09-294-2/+142
| | | | | | | | | | | | | | | | | | loaded at a random offset). To get the kernel's UUID and load address I need to send a kdp packet so I had to implement the kernel relocation (and attempt to find the kernel if none was provided to lldb already) in ProcessKDP -- but this code really properly belongs in DynamicLoaderDarwinKernel. I also had to add an optional Stream to ConnectRemote so ProcessKDP::DoConnectRemote can print feedback about the remote kernel's UUID, load address, and notify the user if we auto-loaded the kernel via the UUID. <rdar://problem/7714201> llvm-svn: 164881
* <rdar://problem/9959501>Greg Clayton2012-09-256-209/+199
| | | | | | More KDP debugging process. We can not set breakpoints, hit them, resume, step and detach while running. llvm-svn: 164584
* Full KDP process control with per CPU resume and step.Greg Clayton2012-09-212-126/+129
| | | | llvm-svn: 164378
* <rdar://problem/9959501>Greg Clayton2012-09-216-6/+192
| | | | | | KDP -- now with rudimentary process control (continue only) and read + write registers (which means we can see stack frames) for x86_64, i386 and ARM. llvm-svn: 164352
* Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. ↵Greg Clayton2012-09-181-3/+3
| | | | | | Some platforms don't support this modification. llvm-svn: 164148
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+2
| | | | | | | | | | | | Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
* <rdar://problem/11358639>Greg Clayton2012-05-081-6/+15
| | | | | | | | Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-1/+1
| | | | | | | | | | | | | No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221
* No functionality changes, mostly cleanup.Greg Clayton2012-04-112-2/+2
| | | | | | | | Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit. Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance. llvm-svn: 154458
* Trying to solve our disappearing thread issues by making thread list updates ↵Greg Clayton2012-04-104-5/+5
| | | | | | | | | | | | | | | | safer. The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the: virtual bool Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, lldb_private::ThreadList &new_thread_list) = 0; A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned. The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue. llvm-svn: 154365
* <rdar://problem/3535148>Han Ming Ong2012-02-252-2/+13
| | | | | | Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
* Add a logging mode that takes a callback and flush'es to that callback.Jim Ingham2012-02-212-11/+9
| | | | | | Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-215-74/+104
| | | | | | | | | | | | | | | | | 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
* Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham2012-02-161-1/+1
| | | | | | | | | class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
* First pass at mach-o core file support is in. It currently works for x86_64 Greg Clayton2012-02-092-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
* Cleaned up the Communication class when it tears down ConnectionFileDescriptorGreg Clayton2012-01-311-4/+2
| | | | | | | | | instances to not pthread_cancel the read threads and wreak havoc on the mutex in our ConnectionFileDescriptor class. Also cleaned up some shutdown delays. llvm-svn: 149355
OpenPOWER on IntegriCloud