summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-071-3/+3
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* Add support for the new (added last week) llvm::Triple::WatchOS and ::TvOSJason Molenda2015-11-051-0/+2
| | | | | | | | | | in places where we check for Triple::IOS. They're mostly the same as far as lldb is conerned. . Also add a base cass implementation for Process::IsAlive - Greg added this last year but it didn't get upstreamed. llvm-svn: 252227
* Add some initial logging for when lldb is searching for binaries,Jason Molenda2015-07-251-0/+10
| | | | | | | | | dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
* Add support for specifying a language to use when parsing breakpoints.Dawn Perchik2015-07-211-0/+1
| | | | | | | | | | | | | | | | | | | | Target and breakpoints options were added: breakpoint set --language lang --name func settings set target.language pascal These specify the Language to use when interpreting the breakpoint's expression (note: currently only implemented for breakpoints on identifiers). If the breakpoint language is not set, the target.language setting is used. This support is required by Pascal, for example, to set breakpoint at 'ns.foo' for function 'foo' in namespace 'ns'. Tests on the language were also added to Module::PrepareForFunctionNameLookup for efficiency. Reviewed by: clayborg Subscribers: jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D11119 llvm-svn: 242844
* Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford2015-07-141-1/+1
| | | | | | | | | | | | | | | | | | | | function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Fix build on OS X after r233061Ilia K2015-03-241-1/+1
| | | | | | | | This includes following: # Add a missing Process argument when calling GetSharedModule in DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule # Fix PlatformDarwinKernel::GetSharedModule prototype llvm-svn: 233084
* If the user specifies a kernel binary that isn't correct for the currentJason Molenda2015-03-101-11/+12
| | | | | | | | | kernel debug session, instead of issuing a warning (which on one ever sees), drop the user-specified kernel binary Module from the target and try to discover the correct one dynamically. <rdar://problem/19450329> llvm-svn: 231885
* Fix build on OS X after r231202Ilia K2015-03-041-0/+1
| | | | llvm-svn: 231235
* Add another address to check for the kernel's load addr in debug configs.Jason Molenda2014-10-061-8/+11
| | | | | | <rdar://problem/18560328> llvm-svn: 219152
* Test suite runs better again after recent fixes that would select a platform ↵Greg Clayton2014-09-191-1/+2
| | | | | | | | | | | | | if a "file a.out" auto selected a different platform than the selected one. Changes include: - fix it so you can select the "host" platform using "platform select host" - change all callbacks that create platforms to returns shared pointers - fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host" - Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform - cache platforms that are created and re-use them instead of always creating a new one llvm-svn: 218145
* When doing an exhaustive search for the kernel in memory, also lookJason Molenda2014-07-311-0/+4
| | | | | | | at 16k offsets. <rdar://problem/17861781> llvm-svn: 214387
* Fix typos.Bruce Mitchener2014-07-081-2/+2
| | | | llvm-svn: 212553
* Add some basic sanity checks to ↵Jason Molenda2014-04-151-0/+24
| | | | | | | | | | DynamicLoaderDarwinKernel::ReadKextSummaryHeader() when it is reading the kext table, in case we're reading out of a core file with corrupt contents in this region. <rdar://problem/16601915> llvm-svn: 206233
* Workaround for collision between enum members in LLVM's MachO.h and system ↵Jim Ingham2014-04-021-1/+1
| | | | | | | | | | headers on Mac OS X (in particular mach/machine.h). <rdar://problem/16494607> llvm-svn: 205480
* Don’t #include “llvm/Support/MachO.h” in a header file if we can avoid ↵Greg Clayton2014-04-021-0/+2
| | | | | | it. llvm-svn: 205460
* Small fix to ↵Jason Molenda2014-03-051-1/+1
| | | | | | | | DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule needed with Greg's change to how we load modules in r202890. llvm-svn: 202933
* Modified ObjectFile::SetLoadAddress() to now be:Greg Clayton2014-02-071-1/+1
| | | | | | | | | | | | | | ObjectFile::SetLoadAddress (Target &target, lldb::addr_t value, bool value_is_offset); Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides. Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing. Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file. llvm-svn: 201003
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-6/+7
| | | | | | | | | | | | 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
* For logical backtrace work, lldb needs to track Module unloads etc & ↵Greg Clayton2013-12-061-1/+1
| | | | | | | | | | 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
* <rdar://problem/15367122>Greg Clayton2013-11-051-1/+1
| | | | | | | | 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
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-1/+1
| | | | | | | | | | 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
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/13635174>Greg Clayton2013-10-111-1/+3
| | | | | | | | 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
* Fix some names in the wake of my Mach-O changes to LLVM.Charles Davis2013-08-271-12/+12
| | | | llvm-svn: 189317
* <rdar://problem/13854277>Greg Clayton2013-05-101-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* Remove the UUID::GetAsCString() method which required a buffer to save the Jason Molenda2013-05-031-8/+4
| | | | | | | UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
* If the Target's current architecture is incompatible with the kernelJason Molenda2013-05-021-0/+5
| | | | | | | DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel re-set the Target's arch based on the kernel's cpu type / cpu subtype. llvm-svn: 180962
* Make the warning message about not finding the kernel binary clearerJason Molenda2013-04-301-1/+1
| | | | | | about which kernel binary lldb is referring to. llvm-svn: 180821
* Cleanup logging to use the new "std::string FileSpec::GetPath()" function. ↵Greg Clayton2013-04-291-8/+2
| | | | | | | | | | | Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
* Remove an unneeded local var, a missing return statement in kernel search ↵Jason Molenda2013-04-191-4/+2
| | | | | | code, thanks to Greg Clayton for finding these. llvm-svn: 179822
* 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
* Change CommandObjectPlatform commands to get the current platformJason Molenda2013-04-051-1/+0
| | | | | | | | | | | from the current Target, if there is one, else back off to getting the currently selected platform from the Debugger (as it ws doing previously.) Remove code from DynamicLoaderDarwinKernel that was setting the platform in both the Target and in the Debugger. llvm-svn: 178836
* Add a new PlatformDarwinKernel for kernel debugging. This PlatformJason Molenda2013-04-051-0/+25
| | | | | | | | | | | | | | | | | | | | | plugin will index the kext bundles on the local filesystem when created. During a kernel debug session, when the DynamicLoader plugin needs to locate a kext by name like "com.apple.com.apple.filesystems.autofs", the Platform can quickly look for a UUID match in those kernel debug kit directories it previously indexed. I'm still working on profiling the performance impact of the inital kext bundle scan; there will likely need to be a switch to enable or disable this plugin's scan. This only affects Mac kernel debugging and the code is only built on Apple systems because of some use of low-level CoreFoundation to parse plists. <rdar://problem/13503583> llvm-svn: 178827
* <rdar://problem/13521159>Greg Clayton2013-03-271-7/+5
| | | | | | | | 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
* Misc. clang build warning fixes.Matt Kopec2013-03-121-1/+1
| | | | llvm-svn: 176879
* ProcessMachCore had (until 2013-01-29) some simple checks to find a kernelJason Molenda2013-03-021-7/+13
| | | | | | | | | | | | | in a core file if it didn't start at the beginning of a memory segment. I added more sophisticated kernel location code to DynamicLoaderDarwinKernel and removed the simple one in ProcessMachCore. Unfortunately the kernel DynamicLoader doesn't get a chance to search around in memory unless there's a hint that this might be a kernel debug session. It was easy ot make the kernel location code static in DynamicLoaderDarwinKernel and call it from ProcessMachCore on the start of the session, so that's what I did. <rdar://problem/13326647> llvm-svn: 176405
* Report the kernel slide when attaching to a darwin kernel debug session.Jason Molenda2013-03-011-0/+9
| | | | llvm-svn: 176311
* When starting a kernel debug session, if the user specified an executableJason Molenda2013-02-271-4/+24
| | | | | | | | binary to lldb already check that the UUID of that binary and the UUID of the kernel binary in memory match. Warn if they don't. <rdar://problem/13184784> llvm-svn: 176160
* If the user has disabled kext loading with theJason Molenda2013-02-261-12/+25
| | | | | | | | | plugin.dynamic-loader.darwin-kernel.load-kexts setting, don't print any messages about loading the kexts (which isn't being done) and don't read the Mach-O headers out of memory (which can be slow and they're not being used for anything at this point). llvm-svn: 176064
* Fix a case where a kext module was being added to the TargetJason Molenda2013-02-191-1/+1
| | | | | | twice. llvm-svn: 175496
* Change the order that the DarwinKernel DynamicLoader plugin usesJason Molenda2013-02-191-38/+14
| | | | | | | | | | | to search for kexts on the local system -- the ModuleList FindModule() method is the best first attempt, only call Symbols::DownloadObjectAndSymbolFile() if that has failed and this is the kernel binary which really needs to have its symbols located. <rdar://problem/13241893> llvm-svn: 175495
* Experiment with printing a warning message when lldb is unable toJason Molenda2013-02-191-1/+11
| | | | | | | | | | | find a binary on the debugger-host during a kernel debug session for a kernel extension (kext). This may prove to be too verbose in typical usage, particularly if there are many third-party kexts. We'll try this and see how it works. <rdar://problem/13080833> llvm-svn: 175494
* Always print the kernel UUID and load address if we are working withJason Molenda2013-02-191-3/+20
| | | | | | | | | | | a kernel binary - even if we can't find the symbol-rich binary or dSYM on the debugger-system. Print a warning if the symbol-rich binary cannot be located. This more closely emulates the gdb behavior when a kernel debug session failed to locate a kernel binary. <rdar://problem/13016095> llvm-svn: 175491
* Change the DarwinKernel DyanmicLoader to maintain a persist listJason Molenda2013-02-191-191/+465
| | | | | | | | | | | | of kernel extensions (kexts) that have been loaded into the kernel. Now when we hit the "kexts have changed" breakpoint we can avoid adding kexts multiple times, and can properly detect kext unloads and remove them from the Target's list of modules. <rdar://problem/13107639> <rdar://problem/13191016> llvm-svn: 175489
* <rdar://problem/13092722>Greg Clayton2013-02-011-2/+2
| | | | | | | | | | Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. llvm-svn: 174222
* Verified that the plugin.dynamic-loader.darwin-kernel.scan-typeJason Molenda2013-01-301-6/+0
| | | | | | | setting is working correctly now; remove the #if 0's around its use. llvm-svn: 173982
* Fix one obvious thinko with the ↵Jason Molenda2013-01-301-2/+2
| | | | | | | | | plugin.dynamic-loader.darwin-kernel.scan-type setting handling that was probably the source of the settings problem. Need to verify that it's working correctly tomorrow though. llvm-svn: 173894
* <rdar://problem/12491235> Jason Molenda2013-01-301-23/+326
| | | | | | | | | | | | | | | | | | | | | | | | | | Enhance lldb so it can search for a kernel in memory when attaching to a remote system. Remove some of the code that was doing this from ProcessMachCore and ProcessGDBRemote and put it in DynamicLoaderDarwinKernel. I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type which can be set to none - for environments where reading random memory can cause a device crash basic - look at one fixed location in memory for a kernel load address, plus the contents of that address fast-scan - the default, tries "basic" and then looks for the kernel's mach header near the current pc value when lldb connects exhaustive-scan - on 32-bit targets, step through the entire range where the kernel can be loaded, looking for the kernel binary I don't have the setting set up correctly right now, I'm getting back unexpected values from the Property system, but I'll figure that out tomorrow and fix. Besides that, all of the different communication methods / types of kernels appear to be working correctly with these changes. llvm-svn: 173891
* <rdar://problem/13069948>Greg Clayton2013-01-251-2/+2
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud