summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/DynamicLoader
Commit message (Collapse)AuthorAgeFilesLines
...
* <rdar://problem/13092722>Greg Clayton2013-02-013-105/+70
| | | | | | | | | | 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
* Add "target.process.stop-on-shared-library-events" setting, and make it work.Jim Ingham2013-01-262-1/+4
| | | | | | | | | | | Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
* <rdar://problem/13069948>Greg Clayton2013-01-255-32/+32
| | | | | | | | | | | | 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
* Remember to tell the target about dyld when we resolve the address for it.Jim Ingham2012-12-221-2/+9
| | | | llvm-svn: 170975
* <rdar://problem/12842032>Greg Clayton2012-12-111-0/+15
| | | | | | Don't load __LINKEDIT segments when dynamically loading kexts. llvm-svn: 169806
* Fix a few more clang (3.2) warnings on Linux:Daniel Malea2012-12-071-1/+1
| | | | | | | | | | | | | | | | | - 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-073-10/+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
* <rdar://problem/12649160>Greg Clayton2012-12-052-2/+56
| | | | | | Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
* 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-294-25/+25
| | | | | | | | - 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-084-18/+15
| | | | | | | | | | | | | | 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
* Fix an incorrect comment...Jim Ingham2012-10-291-0/+2
| | | | llvm-svn: 166959
* 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-297-95/+114
| | | | | | | | | | | | 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
* Add explicit casts to bool in "shared pointer is valid" constructs that ↵Jim Ingham2012-08-111-1/+1
| | | | | | return bool. llvm-svn: 161719
* Removed explicit NULL checks for shared pointersSean Callanan2012-08-091-1/+1
| | | | | | | | | and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
* 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-074-19/+19
| | | | | | Fixed a crasher where the section load list was not thread safe. llvm-svn: 159884
* We were accessing the ModuleList in the target without locking it for tasks likeJim Ingham2012-05-302-4/+8
| | | | | | | | | | | setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
* 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
* Don't do a stat compare of the module with its underlying file if we already ↵Jim Ingham2012-05-161-15/+12
| | | | | | matched the UUID. llvm-svn: 156928
* <rdar://problem/11358639>Greg Clayton2012-05-082-2/+22
| | | | | | | | 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
* Fixed the ability to load multiple __LINKEDIT segments at the same address ↵Greg Clayton2012-04-161-11/+11
| | | | | | for darwin shared cache entries. Now when registering the load address of a section, the DynamicLoader objects can specify if they should warn or not. This will fix the ability to load the nlist entries for shared libraries in the darwin shared caches when no on disk representation is available for a shared library. llvm-svn: 154860
* 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
* Fix the process of getting the ObjC runtime - if we ask for it too early (in ↵Jim Ingham2012-03-101-1/+1
| | | | | | | | | the process of handling the load notification for the first load) then we will set it the runtime to NULL and won't re-search for it. Added a way for the dynamic loader to force a re-search, since it knows the world has changed. llvm-svn: 152453
* <rdar://problem/10997402>Greg Clayton2012-03-072-7/+3
| | | | | | | | | | | 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
* Removed an unused logging API call.Greg Clayton2012-02-291-1/+0
| | | | llvm-svn: 151736
* Added the POSIX-DYLD as a plug-in in the darwin build in the Xcode projectGreg Clayton2012-02-273-13/+15
| | | | | | | | | so that we don't break it with code changes. After doing this I was able to fix the POSIX-DYLD plug-in so that it builds after recent ModuleSpec changes. llvm-svn: 151536
* Made a ModuleSpec class in Module.h which can specify a module using one orGreg Clayton2012-02-262-42/+26
| | | | | | | | | | | | | | | | | | 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
* <rdar://problem/10103468>Greg Clayton2012-02-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
* For stepping performance I added the ability to outlaw all memory accessesesGreg Clayton2012-02-221-19/+60
| | | | | | | | | | | to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't slide __PAGEZERO and it also registers it as an invalid region of memory. This allows us to not make any memory requests from the local or remote debug session for any addresses in this region. Stepping performance can improve when uninitialized local variables that point to locations in __PAGEZERO are attempted to be read from memory as we won't even make the memory read or write request. llvm-svn: 151128
* Linux fix patch from Dmitry Vyukov.Greg Clayton2012-02-212-2/+2
| | | | llvm-svn: 151072
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-4/+6
| | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud