summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands
Commit message (Collapse)AuthorAgeFilesLines
...
* Fixed GetModuleSpecifications() to work better overall:Greg Clayton2013-07-121-1/+1
| | | | | | | | | | | - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects llvm-svn: 186211
* Huge change to clean up types.Greg Clayton2013-07-115-23/+28
| | | | | | | | A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
* Fix "source list -n printf" on Linux (printf is symbol alias for __printf)Michael Sartain2013-07-111-28/+96
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D1109 llvm-svn: 186104
* Add a -remote-file option to “target create” to specify the location of ↵Jim Ingham2013-07-111-2/+15
| | | | | | the executable on a remote system (if debugging remotely using debugserver on the target system.) This gets us closer to being able to set up a remote debugging session from the lldb command line. llvm-svn: 186050
* Cleanup on the unified section list changes. Main changes are:Greg Clayton2013-07-101-2/+2
| | | | | | | | | | | | | | | - ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990
* Add silent option to command source.Michael Sartain2013-07-091-1/+9
| | | | | | Patch from Matthew Sorrels llvm-svn: 185983
* Revert commits that cause broken builds on GCC buildbotsDaniel Malea2013-07-031-3/+1
| | | | | | | | - build fails due to PyCallable template definition inside an extern "C" scope This commit reverts 185240, 184893 and 184608. llvm-svn: 185560
* Use the "last created watchpoint" rather than asserting on watchpoint ↵Jim Ingham2013-07-023-12/+24
| | | | | | | | commands passing no watchpoint ID. <rdar://problem/14327560> llvm-svn: 185406
* Split symbol support for ELF and Linux.Michael Sartain2013-07-011-18/+14
| | | | llvm-svn: 185366
* <rdar://problem/14266578>Enrico Granata2013-06-261-3/+1
| | | | | | "command source" was not properly setting the stop-on-error option llvm-svn: 184899
* <rdar://problem/14243761>Enrico Granata2013-06-261-5/+5
| | | | | | | | | The argument to -w (--category) in type * list is a regular expression This caused unhappiness with the gnu-libstdc++ category because of the double ++ Now we check for exact textual match as-well-as regexp matching llvm-svn: 184898
* <rdar://problem/14266411>Enrico Granata2013-06-251-1/+3
| | | | | | | | | | | | The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened This checkin changes that: - SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string - script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior llvm-svn: 184893
* Sort out a number of mismatched integer types in order to cut down the ↵Andy Gibbs2013-06-193-4/+4
| | | | | | number of compiler warnings. llvm-svn: 184333
* We were getting an assert because somebody was making a watchpoint that wasJim Ingham2013-06-181-7/+8
| | | | | | | | neither read nor write. Tighten up the checking so this isn't possible. <rdar://problem/14111167> llvm-svn: 184245
* Fix the help for "image dump line-table" - its arguments are compilation ↵Jim Ingham2013-06-181-1/+1
| | | | | | units not modules. llvm-svn: 184226
* Renaming the "--wipe" option to "command history" to "--clear" (-C) for ↵Enrico Granata2013-06-171-8/+8
| | | | | | coherence with the rest of the LLDB command-line interface llvm-svn: 184147
* <rdar://problem/14134716>Enrico Granata2013-06-171-24/+106
| | | | | | | | | | | | This is a rewrite of the command history facility of LLDB It takes the history management out of the CommandInterpreter into its own CommandHistory class It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5) It adds a new --wipe (-w) option to command history to allow clearing the history on demand It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be It adds a test case for the reimplemented facility llvm-svn: 184140
* <rdar://problem/11914077>Enrico Granata2013-06-123-85/+22
| | | | | | | If you type help command <word> <word> <word> <missingSubCommand> (e.g. help script import or help type summary fake), you will get help on the deepest matched command word (i.e. script or type summary in the examples) Also, reworked the logic for commands to produce their help to make it more object-oriented llvm-svn: 183822
* <rdar://problem/13779789>Enrico Granata2013-06-111-8/+22
| | | | | | Allow memory read -t to take persistent types (those defined with expression struct $....) llvm-svn: 183766
* Remove eFormatHalfFloat as it isn't needed. eFormatFloat should be used and ↵Greg Clayton2013-06-111-4/+0
| | | | | | the byte size will tell us how to display it. llvm-svn: 183755
* <rdar://problem/12876503>Enrico Granata2013-06-111-6/+9
| | | | | | | Adding a new setting interpreter.stop-command-source-on-error that dictates a default behavior for whether command source should stop upon hitting an error You can still override the setting for each individual invocation with the usual -e setting llvm-svn: 183719
* <rdar://problem/12783351>Enrico Granata2013-06-111-0/+4
| | | | | | | | | | Add support for half-floats, as specified by IEEE-754-2008 With this checkin, you can now say: (lldb) x/7hf foo to read 7 half-floats at address foo llvm-svn: 183716
* Make the "SearchFilterByModuleListAndCU" work correctly for searches at the ↵Jim Ingham2013-06-071-1/+3
| | | | | | | | | | | | | CompUnit level. Fixes a bug in "break set --source-pattern-regexp" when a shared library is specified. Also cleaned up the help text for --source-pattern-regexp so it is a little clearer. <rdar://problem/14084261> llvm-svn: 183476
* <rdar://problem/14086944>Greg Clayton2013-06-071-10/+26
| | | | | | lldb doesn't autocomplete objective C class methods. The regular expression was looking for strings that started with the completion string that was passed in. For objective C class methods, this string starts with "+" which wasn't being escaped. Added many other escapes that were missing just in case. llvm-svn: 183470
* <rdar://problem/13239809>Enrico Granata2013-06-041-6/+8
| | | | | | | | Two things: 1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary 2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before llvm-svn: 183276
* <rdar://problem/12582328>Enrico Granata2013-06-041-9/+54
| | | | | | | | | | If you want to define a formatter for "array of Foo of any size", ordinarily you would say -x "Foo \[[0-9]+\]" this checkin allows you to instead say "Foo[]" (or "Foo []") and LLDB will automatically create the regular expression and add the -x flag on your behalf llvm-svn: 183272
* <rdar://problem/11109316>Enrico Granata2013-05-311-2/+2
| | | | | | | | | | | | | | | | | command script import now does reloads - for real If you invoke command script import foo and it detects that foo has already been imported, it will - invoke reload(foo) to reload the module in Python - re-invoke foo.__lldb_init_module This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing Usual caveats with Python imports persist. Among these: - if you have objects lurking around, reloading the module won't magically update them to reflect changes - if module A imports module B, reloading A won't reload B These are Python-specific issues independent of LLDB that would require more extensive design work The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not llvm-svn: 182977
* For "expr", say what the timeout units are in the help string.Jim Ingham2013-05-291-1/+1
| | | | llvm-svn: 182873
* <rdar://problem/13925432>Enrico Granata2013-05-211-2/+15
| | | | | | | A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted llvm-svn: 182398
* Improving the previous checkin about target.load-script-from-symbol-fileEnrico Granata2013-05-211-1/+4
| | | | | | | | | | There are two settings: target.load-script-from-symbol-file is a boolean that says load or no load (default: false) target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true) the auto loading on change for target.load-script-from-symbol-file is preserved llvm-svn: 182336
* Forgot to check for empty error strings in the previous checkinEnrico Granata2013-05-201-1/+1
| | | | llvm-svn: 182325
* <rdar://problem/13878726>Enrico Granata2013-05-201-1/+8
| | | | | | | | | | | | | | This changes the setting target.load-script-from-symbol-file to be a ternary enum value: default (the default value) will NOT load the script files but will issue a warning suggesting workarounds yes will load the script files no will not load the script files AND will NOT issue any warning if you change the setting value from default to yes, that will then cause the script files to be loaded (the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it) if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value llvm-svn: 182323
* <rdar://problem/11398407>Greg Clayton2013-05-181-1/+1
| | | | | | | | Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be. This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this. llvm-svn: 182179
* Apropos should search user commands as well as built-in commands.Jim Ingham2013-05-171-16/+46
| | | | | | rdar://problem/13916722 llvm-svn: 182068
* <rdar://problem/13217784>Greg Clayton2013-05-171-103/+171
| | | | | | "source list -n <func>" can now show more than one location that matches a function name. It will unique multiple of the same source locations so they don't get displayed. It also handles inline functions correctly. llvm-svn: 182067
* Note in the documentation about the fact that Python callbacks can return a ↵Enrico Granata2013-05-161-0/+6
| | | | | | value and if that value is False, LLDB won’t stop at the breakpoint llvm-svn: 182059
* <rdar://problem/11158023>Enrico Granata2013-05-161-1/+3
| | | | | | Make type summary add and breakpoint command add show an helpful prototype + argument reference when manually typing Python code for these elements llvm-svn: 181968
* <rdar://problem/13128331>Greg Clayton2013-05-151-1/+48
| | | | | | | | Fixed "target symbols add" to correctly extract all module specifications from a dSYM file that is supplied and match the symbol file to a current target module using the UUID values if they are available. This fixes the case where you add a dSYM file (like "foo.dSYM") which is for a renamed executable (like "bar"). In our case it was "mach_kernel.dSYM" which didn't match "mach_kernel.sys". llvm-svn: 181916
* <rdar://problem/13883385>Enrico Granata2013-05-151-1/+2
| | | | | | | | | | | Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing: a) the SWIG wrapper was not checking the return value of the script b) when passing a Python function by name, the call statement was dropping the return value of the function This checkin addresses both concerns and makes this work Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop! llvm-svn: 181866
* A first pass at auto completion for variables and their children. This is ↵Greg Clayton2013-05-142-0/+41
| | | | | | currently hooked up for "frame variable" only. With a little work we can also enable it for the "expression" command and also for other things. llvm-svn: 181850
* <rdar://problem/13183720>Enrico Granata2013-05-131-0/+4
| | | | | | | | Provide a mechanism through which users can disable loading the Python scripts from dSYM files This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script") You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load llvm-svn: 181709
* A couple of small fixes to make core file debugging less noisy.Jason Molenda2013-05-111-3/+4
| | | | | | | | | | Don't want about being unable to find a needed objective-c runtime function when we're core file debugging and can't jit anything anyway. Don't warn when quitting a debug session on a core file, the program state can be reconstructed by re-running lldb on the same core file again. llvm-svn: 181653
* <rdar://problem/13700260>Greg Clayton2013-05-101-6/+3
| | | | | | Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state. llvm-svn: 181651
* <rdar://problem/13854277>Greg Clayton2013-05-103-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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
* <rdar://problem/13831149>Enrico Granata2013-05-091-0/+7
| | | | | | | | Recursive commands invocations are not currently supported by our CommandInterpreter CommandScriptImport can actually be made to invoke itself recursively, so we need to work around that by clearing the m_exe_ctx This is a short-term workaround, a more interesting solution would be to actually make sure recursive command invocations work properly llvm-svn: 181537
* A few small fixes to make things like image list notJason Molenda2013-05-061-6/+3
| | | | | | | print "//mach_kernel" if you are debugging an executable in the top level directory. llvm-svn: 181190
* Remove the UUID::GetAsCString() method which required a buffer to save the Jason Molenda2013-05-031-8/+6
| | | | | | | UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
* <rdar://problem/13788674>Greg Clayton2013-05-021-1/+1
| | | | | | TestPlatformCommand failing on buildbot. llvm-svn: 180963
* Recommitting r180831 with trivial fix - remember to return errors if you ↵Jim Ingham2013-05-021-3/+98
| | | | | | compute. llvm-svn: 180898
* Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.pyDaniel Malea2013-05-011-98/+3
| | | | llvm-svn: 180868
OpenPOWER on IntegriCloud