summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Platform
Commit message (Collapse)AuthorAgeFilesLines
...
* <rdar://problem/13875830>Greg Clayton2013-05-132-1/+35
| | | | | | Unblock linux builds. The real fix for this is tracked by the above radar, but this temporary hack should fix things for now. llvm-svn: 181717
* <rdar://problem/13854277>Greg Clayton2013-05-1015-162/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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
* Small adjustment to PlatformDarwinKernel::ExamineKextForMatchingUUID toJason Molenda2013-05-031-3/+11
| | | | | | | help performance -- if the FileSpec we're examining does not contain the UUID we're looking for, don't bother examining the file any further. llvm-svn: 181063
* Pass down the architecture of the module we're trying toJason Molenda2013-05-032-3/+4
| | | | | | | match when looking at kext on the local filesystem. <rdar://problem/13785112> llvm-svn: 180989
* Cleanup logging to use the new "std::string FileSpec::GetPath()" function. ↵Greg Clayton2013-04-295-49/+26
| | | | | | | | | | | 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
* Add a final fall-back to PlatformDarwin::GetDeveloperDirectory() whichJason Molenda2013-04-291-0/+37
| | | | | | | | | will run xcode-select --print-path to find the currently selected Xcode developer directory. Mostly useful for when lldb is not being run out of the /Applications/Xcode.app bundle so it can't locate the iOS or kernel SDKs. llvm-svn: 180705
* Add a few new methods to FileSpec to make it a little easier to workJason Molenda2013-04-291-74/+54
| | | | | | | | | | | with directories, without increasing the size of the FileSpec object. GetPath() returns a std::string of the full pathname of the file. IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink() can be used instead of getting the FileType() and comparing it to an enum. Update PlatformDarwinKernel to use these new methods. llvm-svn: 180704
* More CMake fixes for OS X.Filipe Cabecinhas2013-04-251-4/+10
| | | | llvm-svn: 180243
* Also look for kexts in /Library/Extensions if that directory exists.Jason Molenda2013-04-231-0/+6
| | | | llvm-svn: 180154
* 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 the default for PlatformDarwinKernel to be enabled a laJason Molenda2013-04-121-1/+1
| | | | | | settings set platform.plugin.darwin-kernel.search-locally-for-kexts true llvm-svn: 179348
* cmake build of lldb was complaining about missing files.Sylvestre Ledru2013-04-111-0/+1
| | | | | | | | | Example: CMake Error at cmake/modules/LLVMProcessSources.cmake:89 (message): Found unknown source file /llvm-toolchain-3.3~svn179293.cmake/tools/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp llvm-svn: 179295
* Update PlatformDarwinKernel::GetMacDirectoriesToSearch to also tryJason Molenda2013-04-081-0/+6
| | | | | | | /Volumes/KernelDebugKit (the default mount point for the Kernel Debug Kit dmgs). llvm-svn: 179058
* Change the default of 'platform.plugin.darwin-kernel.search-locally-for-kexts'Jason Molenda2013-04-061-1/+1
| | | | | | to 'off' for a week or so while we test the behavior in different environments. llvm-svn: 178951
* Reorder the Platform plugin settings so that they're nowJason Molenda2013-04-051-15/+20
| | | | | | | | | platform.plugin.darwin-kernel.kext-directories platform.plugin.darwin-kernel.search-locally-for-kexts and fix a few FileSpec handling issues for the kext-directories setting. llvm-svn: 178920
* Add support for Platform plugins to have settings.Jason Molenda2013-04-052-3/+132
| | | | | | | | | Add two initial settings for the PlatformDarwinKernel plugin, plugin.platform.darwin-kernel.search-locally-for-kexts [true|false] plugin.platform.darwin-kernel.kext-directories [directory list] llvm-svn: 178846
* Add a new PlatformDarwinKernel for kernel debugging. This PlatformJason Molenda2013-04-052-0/+709
| | | | | | | | | | | | | | | | | | | | | 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
* Revert code I didn't mean to check in.Greg Clayton2013-04-041-5/+2
| | | | llvm-svn: 178718
* Playing around with making performance test cases run from within python. Greg Clayton2013-04-031-2/+5
| | | | llvm-svn: 178708
* Update PlatformDarwin to understand how armv7m / armv7em relateJason Molenda2013-03-081-12/+54
| | | | | | | | to the other armv7 types as far as compatibility/interchangability goes. <rdar://problem/13361372> llvm-svn: 176684
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-215-0/+28
| | | | | | | | | | | | | | - 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
* <rdar://problem/13218655>Greg Clayton2013-02-141-23/+42
| | | | | | "target modules add" should resolve bundle executables, as should anything else that tries to create a module from a bundle path. llvm-svn: 175210
* Add "target.process.stop-on-shared-library-events" setting, and make it work.Jim Ingham2013-01-261-0/+1
| | | | | | | | | | | 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
* Don't always strip the first extension from the module basename when looking ↵Greg Clayton2013-01-121-19/+37
| | | | | | for python scripts. Now we take a name like "a.b.c" and look for scripts that are "a_b_c.py", "a_b.py" and "a.py" inside the dSYM. llvm-svn: 172291
* <rdar://problem/12973809> Greg Clayton2013-01-112-79/+51
| | | | | | | | | | | | | Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library. The modifications will now: - Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found. - Don't try and do any of this if the script interpreter has scripting disabled. - Allow more than one scripting resource to be found in a symbol file by returning the list - Load the scripting resources when a symbol file is added via the "target symbols add" command. - Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed. llvm-svn: 172275
* <rdar://problem/12968925>Enrico Granata2013-01-081-0/+7
| | | | | | Ensuring that the Module's FileSpec is not NULL before attempting to deref it for loading the python scripting resource llvm-svn: 171838
* Clarify the comments in PlatformDarwin::LocateExecutableScriptingResourceJason Molenda2012-12-201-7/+9
| | | | | | a bit. llvm-svn: 170641
* <rdar://problem/12903081>Enrico Granata2012-12-201-2/+20
| | | | | | | When looking for the Python script to load for a given module, replace dots with underscores if there are any after stripping the extension This means that for a module named foo.devel.xyz a file named foo_devel.py will be what we try to load llvm-svn: 170633
* Removed the == and != operators from ArchSpec, sinceSean Callanan2012-12-132-2/+2
| | | | | | | | | | | | equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-054-0/+8
| | | | | | | | | - 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
* Fixed a potential crash in the Darwin platform.Sean Callanan2012-11-121-1/+4
| | | | llvm-svn: 167732
* Don't assume that Modules have directories. They may be in-memory-onlyJason Molenda2012-11-101-1/+1
| | | | | | | things like our favorite "cl_kernels" and so module_directory here can be NULL. llvm-svn: 167666
* Adding support for loading the scripting resource as part of a framework, ↵Enrico Granata2012-11-081-2/+23
| | | | | | | | lacking the dSYM bundle, or if the bundle has no Pythonic resources whatsoever Solving an issue where "command script import" would fail to pick the file indicated by the user as a result of something with the same name being in an earlier position in sys.path llvm-svn: 167570
* <rdar://problem/12586350>Enrico Granata2012-11-082-0/+35
| | | | | | | | | | | | | | 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
* Make sure to check the module is valid after trying to find a shared module.Greg Clayton2012-11-061-1/+1
| | | | llvm-svn: 167471
* Also remove PlatformiOSSimulator::GetProcessInfo decl fromJason Molenda2012-10-201-4/+0
| | | | | | | the header file. (followup patch to Sean's commit of r166355 earlier today.) llvm-svn: 166365
* Fixed the iOS simulator platform:Sean Callanan2012-10-201-9/+1
| | | | | | | | | | - Fixed a crash when the executable module couldn't be found. - Fixed a problem that made it impossible to attach to processes in the simulator using the SBTarget::Attach. llvm-svn: 166355
* <rdar://problem/12462048>Greg Clayton2012-10-184-8/+4
| | | | | | | | | | <rdar://problem/12068650> More fixes to how we handle paths that are used to create a target. This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing". llvm-svn: 166186
* Add support for debugging KASLR kernels via kdp (the kernel beingJason Molenda2012-09-291-1/+1
| | | | | | | | | | | | | | | | | | 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
* The iOSSimulator platform should create a PlatformDarwin with Jason Molenda2012-09-251-1/+1
| | | | | | | is_host == true so PlatformDarwin knows it can do same-host operations like process lookup. <rdar://problem/12296249> llvm-svn: 164647
* <rdar://problem/11374963>Greg Clayton2012-09-122-0/+33
| | | | | | Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform. llvm-svn: 163676
* Patch from Andrew Kaylor for linux:Greg Clayton2012-09-071-0/+11
| | | | | | | | | | | | | | | The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system. Making this work required two basic changes: 1) Getting lldb to report that it could debug 32-bit processes 2) Changing an assumption about how ptrace works when debugging cross-platform For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms. It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure. For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size. However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant." I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written. llvm-svn: 163398
* Patch from Daniel Malea to fix the build on Linux. ThanksEnrico Granata2012-09-061-1/+1
| | | | llvm-svn: 163332
* <rdar://problem/12211320>Greg Clayton2012-09-055-11/+50
| | | | | | When the vendor and OS are not specified in a triple, only let unspecified vendor and OS fields matchs for the current host platform. llvm-svn: 163248
* Fixed a potential crash in PlatformLinux ifSean Callanan2012-08-291-1/+2
| | | | | | | | ModuleList::GetSharedModule() returned NULL. <rdar://problem/12182971> llvm-svn: 162871
* <rdar://problem/11757916>Greg Clayton2012-08-295-0/+8
| | | | | | | | | | | | 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
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-222-1/+15
| | | | | | | | | | | | | issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-0/+1
| | | | llvm-svn: 160338
* Make sure the module_uuid_ptr is non-NULL before checking whether its ↵Jim Ingham2012-06-051-2/+2
| | | | | | contents match the module's UUID. llvm-svn: 157971
* Check for NULL modules coming into the SearchFilter's ModulePasses & ↵Jim Ingham2012-05-291-0/+3
| | | | | | PlatformDarwin::ModuleIsExcludedForNonModuleSpecificSearches functions. llvm-svn: 157653
OpenPOWER on IntegriCloud