summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands/CommandObjectTarget.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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/13563628>Enrico Granata2013-04-051-1/+1
| | | | | | | | | | Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache() This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them. In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols). Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added. Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic. llvm-svn: 178897
* Our commands that end up displaying a ValueObject as part of their workflow ↵Enrico Granata2013-03-261-12/+1
| | | | | | | | | | | use OptionGroupValueObjectDisplay as their currency for deciding the final representation ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code This checkin provides one and only one (and hopefully correct :-) entry point for this conversion llvm-svn: 178044
* Convert the -a option in "image lookup" to a address-expression, and pass ↵Jim Ingham2013-03-151-6/+8
| | | | | | | | the context in the -a address expression lookup in "image list" so that it actually works. llvm-svn: 177200
* Change CommandObjectTargetSymbolsAdd to require that a target exists;Jason Molenda2013-02-021-1/+1
| | | | | | | | | | | | fixes crash of the form % lldb (lldb) target symbols add /tmp/symbols.dSYM (lldb) Killed: 9 <rdar://problem/13139481> llvm-svn: 174267
* <rdar://problem/12552374>Enrico Granata2013-01-291-1/+1
| | | | | | | Replacing the address argument type with address-expression in cases where StringToAddress() is used, and hence an expression can be passed where previously only a numeric address was allowed This makes the documentation more clear and helps users discover that they can truly pass in an expression in these situations. llvm-svn: 173753
* <rdar://problem/12524607>Greg Clayton2013-01-291-1/+5
| | | | | | | | | | | Flush the process when symbols are loaded/unloaded manually. This was going on in: - "target modules load" command - SBTarget::SetSectionLoadAddress(...) - SBTarget::ClearSectionLoadAddress(...) - SBTarget::SetModuleLoadAddress(...) - SBTarget::ClearModuleLoadAddress(...) llvm-svn: 173745
* <rdar://problem/13069948>Greg Clayton2013-01-251-41/+41
| | | | | | | | | | | | 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/12973809> Greg Clayton2013-01-111-2/+24
| | | | | | | | | | | | | 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
* Expanded the flags that can be set for a command object in ↵Greg Clayton2013-01-091-361/+330
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb_private::CommandObject. This list of available flags are: enum { //---------------------------------------------------------------------- // eFlagRequiresTarget // // Ensures a valid target is contained in m_exe_ctx prior to executing // the command. If a target doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidTargetDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidTargetDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresTarget = (1u << 0), //---------------------------------------------------------------------- // eFlagRequiresProcess // // Ensures a valid process is contained in m_exe_ctx prior to executing // the command. If a process doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidProcessDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidProcessDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresProcess = (1u << 1), //---------------------------------------------------------------------- // eFlagRequiresThread // // Ensures a valid thread is contained in m_exe_ctx prior to executing // the command. If a thread doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidThreadDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidThreadDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresThread = (1u << 2), //---------------------------------------------------------------------- // eFlagRequiresFrame // // Ensures a valid frame is contained in m_exe_ctx prior to executing // the command. If a frame doesn't exist or is invalid, the command // will fail and CommandObject::GetInvalidFrameDescription() will be // returned as the error. CommandObject subclasses can override the // virtual function for GetInvalidFrameDescription() to provide custom // strings when needed. //---------------------------------------------------------------------- eFlagRequiresFrame = (1u << 3), //---------------------------------------------------------------------- // eFlagRequiresRegContext // // Ensures a valid register context (from the selected frame if there // is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx) // is availble from m_exe_ctx prior to executing the command. If a // target doesn't exist or is invalid, the command will fail and // CommandObject::GetInvalidRegContextDescription() will be returned as // the error. CommandObject subclasses can override the virtual function // for GetInvalidRegContextDescription() to provide custom strings when // needed. //---------------------------------------------------------------------- eFlagRequiresRegContext = (1u << 4), //---------------------------------------------------------------------- // eFlagTryTargetAPILock // // Attempts to acquire the target lock if a target is selected in the // command interpreter. If the command object fails to acquire the API // lock, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagTryTargetAPILock = (1u << 5), //---------------------------------------------------------------------- // eFlagProcessMustBeLaunched // // Verifies that there is a launched process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBeLaunched = (1u << 6), //---------------------------------------------------------------------- // eFlagProcessMustBePaused // // Verifies that there is a paused process in m_exe_ctx, if there // isn't, the command will fail with an appropriate error message. //---------------------------------------------------------------------- eFlagProcessMustBePaused = (1u << 7) }; Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands. llvm-svn: 171990
* Remove the “len” defaulted parameter from ↵Jim Ingham2012-12-151-3/+3
| | | | | | CommandReturnObject::AppendMessage, AppendWarning and AppendError. Nobody was using them, and it meant if you accidentally used the AppendWarning when you meant AppendWarningWithFormat with an integer in the format string, it would compile and then return your string plus some unknown amount of junk. llvm-svn: 170266
* Cleaned up the UUID mismatch just printing itself whenever it wants to by ↵Greg Clayton2012-12-141-1/+1
| | | | | | allowing an optional feedback stream to be passed along when getting the symbol vendor. llvm-svn: 170174
* Made "target modules add" flush the process toSean Callanan2012-12-131-0/+16
| | | | | | | | reset stack frames etc. <rdar://problem/12842024> llvm-svn: 170079
* <rdar://problem/12780507>Greg Clayton2012-12-121-62/+100
| | | | | | Fix add-dsym ("target symbols add") to correctly add a dSYM file when the target arch doesn't match the arch of the module. llvm-svn: 169952
* <rdar://problem/12820334>Greg Clayton2012-12-061-8/+3
| | | | | | | | | | | | | I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
* 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/12798131> Greg Clayton2012-12-041-43/+154
| | | | | | | | | | | | Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite. This fix does the following: - make sure all short options are treated as "int" - make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired - fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates - fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value llvm-svn: 169189
* Added new options to "target create" and "target modules add".Greg Clayton2012-11-301-5/+36
| | | | | | | | | | For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file: (lldb) target create --symfile /tmp/a.dSYM /usr/bin/a Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer. llvm-svn: 169023
* <rdar://problem/12687087>Greg Clayton2012-11-291-6/+85
| | | | | | | | Emit an error when using "target modules add PATH" where PATH points to a debug info only (dSYM) file. Also added a "--uuid" option for "target modules add --uuid UUID" to locate and load a module by UUID if the host supports it. llvm-svn: 168949
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-13/+13
| | | | | | | | - 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-4/+4
| | | | | | | | | | | | | | 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 users know that "target variable" can read variables while running ↵Greg Clayton2012-11-031-1/+1
| | | | | | a process by changing the documentation string. llvm-svn: 167343
* <rdar://problem/12570550>Greg Clayton2012-10-251-7/+0
| | | | | | TOT lldb broke finding App in app bundles when launching with shell. llvm-svn: 166733
* This is a fix for the command option parser.Sean Callanan2012-10-241-5/+5
| | | | | | | | | | | | | | | | There was a generic catch-all type for path arguments called "eArgTypePath," and a specialized version called "eArgTypeFilename." It turns out all the cases where we used eArgTypePath we could have used Filename or we explicitly meant a directory. I changed Path to DirectoryName, made it use the directory completer, and rationalized the uses of Path. <rdar://problem/12559915> llvm-svn: 166533
* <rdar://problem/12462048>Greg Clayton2012-10-181-14/+6
| | | | | | | | | | <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
* <rdar://problem/12462048>Greg Clayton2012-10-171-0/+7
| | | | | | | | | | | | | | | | | | | LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings: target.arg0 (string) = There is also the program argument that are separate from the first argument that have existed for a while: target.run-args (arguments) = When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the: - resolved executable path - argv0 - program args Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision. llvm-svn: 166137
* Bunch of cleanups for warnings found by the llvm static analyzer.Jim Ingham2012-10-121-3/+15
| | | | llvm-svn: 165808
* Ran the sources through the compiler with -Wshadow warningsJason Molenda2012-10-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | enabled after we'd found a few bugs that were caused by shadowed local variables; the most important issue this turned up was a common mistake of trying to obtain a mutex lock for the scope of a code block by doing Mutex::Locker(m_map_mutex); This doesn't assign the lock object to a local variable; it is a temporary that has its dtor called immediately. Instead, Mutex::Locker locker(m_map_mutex); does what is intended. For some reason -Wshadow happened to highlight these as shadowed variables. I also fixed a few obivous and easy shadowed variable issues across the code base but there are a couple dozen more that should be fixed when someone has a free minute. <rdar://problem/12437585> llvm-svn: 165269
* Wrapped up the work I am going to do for now for the "add-dsym" or "target ↵Greg Clayton2012-09-271-111/+233
| | | | | | | | | | | | | | | | | | | | symfile add" command. We can now do: Specify a path to a debug symbols file: (lldb) add-dsym <path-to-dsym> Go and download the dSYM file for the "libunc.dylib" module in your target: (lldb) add-dsym --shlib libunc.dylib Go and download the dSYM given a UUID: (lldb) add-dsym --uuid <UUID> Go and download the dSYM file for the current frame: (lldb) add-dsym --frame llvm-svn: 164806
* Added the ability to download a symboled executable and symbol file given a ↵Greg Clayton2012-09-271-1/+42
| | | | | | UUID. llvm-svn: 164753
* Made the help for the -n option onSean Callanan2012-09-131-13/+13
| | | | | | | | | | "target image lookup" a bit better documented by indicating that it takes symbols OR functions. <rdar://problem/12281325> llvm-svn: 163839
* <rdar://problem/11374963>Greg Clayton2012-09-121-1/+10
| | | | | | 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
* Change the NULL to a 0 since we need a uint32_tFilipe Cabecinhas2012-09-111-6/+6
| | | | llvm-svn: 163625
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+3
| | | | | | | | | | | | 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
* Fix a redundant computation.Johnny Chen2012-08-281-1/+1
| | | | llvm-svn: 162794
* rdar://problem/11324515Johnny Chen2012-08-221-1/+20
| | | | | | | 'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file. llvm-svn: 162332
* rdar://problem/12096295Johnny Chen2012-08-151-1/+1
| | | | | | | Add an lldb command line option to specify a core file: --core/-c. For consistency, change the "target create" command to also use --core. llvm-svn: 161993
* Add a new 'target modules show-unwind' command to show the differentJason Molenda2012-07-121-0/+237
| | | | | | | | | | | | UnwindPlans for a function. This specifically does not use any previously-generated UnwindPlans so if any logging is performed while creating the UnwindPlans, it will be repeated. This is useful for when an lldb stack trace is not correct and you want to gather diagnostic information from the user -- they can do log enable -v lldb unwind, image show-unwind of the function, and you'll get the full logging as the UnwindPlans are recreated. llvm-svn: 160095
* Fixed an issue where if you ask to search the global list of modules for a ↵Greg Clayton2012-07-111-21/+22
| | | | | | module with "target modules list", if it found a match in the current target, it would skip looking at the global list. Now if you ask for the global list, we use it and skip the target. llvm-svn: 160072
* Make error messages more user-friendly for the 'target delete' command.Filipe Cabecinhas2012-07-091-3/+15
| | | | llvm-svn: 159927
* <rdar://problem/11357711>Greg Clayton2012-07-071-1/+1
| | | | | | Fixed a crasher where the section load list was not thread safe. llvm-svn: 159884
* Fixed the "target modules list" to not crash in Debug builds due to an ↵Greg Clayton2012-06-271-2/+4
| | | | | | assertion where the mutex in the "module_list" local variable would assert when the lldb_private::Mutex would destruct. What was happening was the mutex in the module list was being locked by a local locker object and then "module_list" would get destroyed before the locker and the locker still had the mutex locked which would cause the pthread call to destroy the mutex to fail with "Resource busy" and it would cause a mutex leak. llvm-svn: 159291
* Make raw & parsed commands subclasses of CommandObject rather than having ↵Jim Ingham2012-06-081-283/+297
| | | | | | | | | | | | | | | | the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
* Added the --all argument to "target modules lookup"Sean Callanan2012-06-061-3/+130
| | | | | | | | | | | | | that forces all matches to be looked up. When --all is not passed, and the current execution frame can be used to narrow down the search, "target modules lookup" will try searching in that specific frame first. Only if nothing is turned up there will it go on to search all modules. This feature is currently enabled only for types. llvm-svn: 158107
* -i option should apply to "-n" as well as "-F".Jim Ingham2012-06-041-2/+2
| | | | llvm-svn: 157960
* We were accessing the ModuleList in the target without locking it for tasks likeJim Ingham2012-05-301-13/+30
| | | | | | | | | | | 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
* <rdar://problem/11386214>Greg Clayton2012-05-181-4/+12
| | | | | | | | | | | <rdar://problem/11455913> "target symbol add" should flush the cached frames "register write" should flush the thread state in case registers modifications change stack llvm-svn: 157042
* Modified "image lookup -t <typename>" to expand typedefs.Greg Clayton2012-05-151-1/+13
| | | | llvm-svn: 156845
* <rdar://problem/11455398>Greg Clayton2012-05-151-88/+139
| | | | | | | | Add "--name" option to "image lookup" that will search both functions and symbols. Also made all of the output from any of the "image lookup" commands be the same regardless of the lookup type (function name, symbol name, func or symbol, file and line, address, etc). The --verbose or -v option also will expand the results as needed and display things so they look the same. llvm-svn: 156835
OpenPOWER on IntegriCloud