summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/DynamicLoader/Darwin-Kernel
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-022-7/+16
| | | | | | | | | | | | | 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
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+5
| | | | | | | | | | | | | | - 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
* 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-192-41/+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-192-284/+597
| | | | | | | | | | | | 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-302-24/+343
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/12842032>Greg Clayton2012-12-111-0/+15
| | | | | | Don't load __LINKEDIT segments when dynamically loading kexts. llvm-svn: 169806
* More Linux warnings fixes (remove default labels as needed):Daniel Malea2012-12-071-3/+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
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - 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
* Don't re-add kexts and the kernel each time we get a notificationJason Molenda2012-12-011-14/+10
| | | | | | | | | | | | | | | | that kexts were newly added. The Darwin userland dynamic loader provides lldb with a list of newly-added or newly-removed binaries but in the kernel case we only know that something has changed. DynamicLoaderDarwinKernel really needs to maintain its own persistent list of kexts that it has been notified about (most importantly, it will not detect kext unlods) but for now we'll at least avoid re-adding an already present kext. <rdar://problem/12658487>, <rdar://problem/12658487> llvm-svn: 169082
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-5/+5
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* <rdar://problem/12586350>Enrico Granata2012-11-081-5/+2
| | | | | | | | | | | | | | This commit does three things: (a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress (b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds (c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment: - the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself) - if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine llvm-svn: 167569
* Fix a crasher in Jason Molenda2012-11-081-1/+2
| | | | | | | | | DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule where it assumed that a kernel had been found in memory, when that may not be the case when we're attaching to a device early in the boot process. <rdar://problem/12638140> llvm-svn: 167564
* Change the name of the variable used to detect if we are loading kexts to ↵Greg Clayton2012-10-191-6/+6
| | | | | | | | | "load-kexts" instead of "disable-kext-loading" since the value is a boolean. This was requested by the person who requested the feature. It now defaults to true: (lldb) settings show plugin.dynamic-loader.darwin-kernel.load-kexts plugin.dynamic-loader.darwin-kernel.load-kexts (boolean) = true llvm-svn: 166315
* Rename "macosx-kernel" to "darwin-kernel" to match the filenames before ↵Greg Clayton2012-10-191-2/+2
| | | | | | anyone starts using the settings for this plug-in. llvm-svn: 166295
* Added the infrastructure necessary for plug-ins to be able to add their own ↵Greg Clayton2012-10-192-2/+72
| | | | | | | | | | | | | | | | | settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at: plugin dynamic-loader macosx-kernel (bool) disable-kext-loading To settings can be set using: (lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins. llvm-svn: 166294
* Add a new target setting to disable automatic loading of kext imagesJason Molenda2012-10-192-3/+13
| | | | | | | | | | in a kernel debug session: settings set target.disable-kext-loading true <rdar://problem/12490623> llvm-svn: 166262
* Bunch of cleanups for warnings found by the llvm static analyzer.Jim Ingham2012-10-121-1/+1
| | | | llvm-svn: 165808
* Add a parameter to Symbols::DownloadObjectAndSymbolFile() to controlJason Molenda2012-10-091-57/+73
| | | | | | | | | | | | | | | | | | | whether we try to call an external program to load symbols unconditionally, or if we check the user's preferences before calling it. ProcessMachCore now sets CanJIT to false - we can't execute code in a core file. DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule changed to load the kernel from an on-disk file if at all possible. Don't load the kext binaries out of memory from the remote systems - their linkedit doesn't seem to be in a good state and we'll error out down in SymbolVendorMacOSX if we try to use the in-memory images. Call Symbols::DownloadObjectAndSymbolFile to get the kext/kernel binary -- the external program may be able to give us a file path on the local filesystem instead of reading the binary / dSYM over a network drive every time. Fall back to calling Target::GetSharedModule() like before if DownloadObjectAndSymbolFile fails. llvm-svn: 165471
* In ↵Jason Molenda2012-10-061-40/+18
| | | | | | | | | | | | | | | | | | DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule(), if we have a kernel binary, set the target's architecture to match. Include the target's architecture in the ModuleSpec when we're searching for the kext binaries on the local system -- otherwise we won't get a specific slice of a fat file picked out for us and we won't use the returned Module correctly. Remove the redundant attempt to find a file on the local filesystem from this method. In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark the canJIT as false. There is no jitting code in kernel debug sessions. llvm-svn: 165357
* Patch submitted by Dan Malea -- I introduced a dependency betweenJason Molenda2012-10-041-1/+2
| | | | | | | ProcessGDBRemote and DynamicLoaderDarwinKernel and a patch was needed to get this building on Linux. Thanks! llvm-svn: 165193
* The kernel loading code is now isolated in the DynamicLoaderDarwinKernel;Jason Molenda2012-10-031-6/+0
| | | | | | | | | | 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
* Change DynamicLoaderDarwinKernel::OSKextLoadedKextSummary to useJason Molenda2012-10-021-10/+16
| | | | | | | | | | | | | | | | | the Symbols::LocateExecutableObjectFile method to locate kexts and kernels instead of copying them out of the memory of the remote system. This is the fix for <rdar://problem/12416384>. Fix a variable shadowing problem in Symbols::LocateMacOSXFilesUsingDebugSymbols which caused the symbol rich executable binaries to not be found even if they were listed in the dSYM Info.plist. Change Symbols::DownloadObjectAndSymbolFile to ignore dsymForUUID's negative cache - this is typically being called by the user and we should try even if there's a incorrect entry in the negative cache. llvm-svn: 165061
* Handle KASLR kernel loading for kernel corefiles.Jason Molenda2012-10-021-37/+71
| | | | | | | | Reduce the amount of output that DynamicLoaderDarwinKernel prints for each kext it loads. <rdar://problem/7714201> llvm-svn: 164985
* Add support for debugging KASLR kernels via kdp (the kernel beingJason Molenda2012-09-291-3/+29
| | | | | | | | | | | | | | | | | | 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/11757916>Greg Clayton2012-08-292-38/+54
| | | | | | | | | | | | 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
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-1/+0
| | | | llvm-svn: 160338
* <rdar://problem/11357711>Greg Clayton2012-07-071-4/+4
| | | | | | Fixed a crasher where the section load list was not thread safe. llvm-svn: 159884
* Also push file & line breakpoints past the prologue. Also added a "-K" ↵Jim Ingham2012-05-221-3/+3
| | | | | | | | | | | argument to the relevant "break set" commands to set this per breakpoint. Also, some CreateBreakpoint API's in the lldb_private namespace had "internal" first and "skip_prologue" second. "internal should always be last. Fixed that. rdar://problem/11484729 llvm-svn: 157225
* <rdar://problem/11358639>Greg Clayton2012-05-081-1/+11
| | | | | | | | 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
* Commit missing function prototype.Greg Clayton2012-03-211-0/+3
| | | | llvm-svn: 153223
* Fixed the ability to load a module from a path by using just a UUID. AfterGreg Clayton2012-03-211-23/+24
| | | | | | | | | the migration to ModuleSpec objects this broke and is now fixed. Also fixed a case in the darwin kernel dynamic loader where we just need to trust the load address of the kernel if we can't read it from memory. llvm-svn: 153164
* <rdar://problem/10997402>Greg Clayton2012-03-071-1/+1
| | | | | | | | | | | This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
* Made a ModuleSpec class in Module.h which can specify a module using one orGreg Clayton2012-02-261-1/+5
| | | | | | | | | | | | | | | | | | more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
* Made loading sections in the DynamicLoaderDarwinKernel more robust as itGreg Clayton2012-02-141-31/+28
| | | | | | | | | seems that sections in the memory module might be quite different from the sections in the file module. Now we find all segments in the on disk file and find that segment by name in the memory module and it is ok if any sections from the file are missing in the memory image. llvm-svn: 150443
* Full core file support has been added for mach-o core files.Greg Clayton2012-02-132-559/+186
| | | | | | | | | | | | | | | | Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
* Improved detection of object file types, movingSean Callanan2012-02-101-9/+1
| | | | | | | | | | detection of kernels into the object file and adding a new category for raw binary images. Fixed all clients who previously searched for sections manually, making them use the object file's facilities instead. llvm-svn: 150272
* Added code in the Host layer that can report system log messagesGreg Clayton2012-01-051-11/+10
| | | | | | | | | | | | so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere. Changed all needed locations over to using this. For non-darwin, we log to stderr only. On darwin, we log to stderr _and_ to ASL (Apple System Log facility). This will allow GUI apps to have a place for these error and warning messages to go, and also allows the command line apps to log directly to the terminal. llvm-svn: 147596
OpenPOWER on IntegriCloud