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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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/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
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
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
unwind instructions for a function/symbol which contains that
address.
Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.
llvm-svn: 180079
to '-A'.
Add option '-a' / '--address' to disassemble which will find the
function that contains that address, and disassemble the entire function.
<rdar://problem/13436207>
llvm-svn: 179258
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
from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)
Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.
llvm-svn: 178836
“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.
<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>
llvm-svn: 178324
- Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable.
Thanks to Greg Clayton for his review feedback.
llvm-svn: 178252
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
Make register read and write accept $<regname> as valid.
This allows:
(lldb) reg read rbx
rbx = 0x0000000000000000
(lldb) reg read $rbx
rbx = 0x0000000000000000
(lldb) reg write $rbx 1
(lldb) reg read $rbx
rbx = 0x0000000000000001
to function correctly
It is not done at the RegisterContext level because we should keep the internal API clean of this user-friendly behavior and name registers appropriately.
If this ends up being needed in more places we can reconsider.
llvm-svn: 177961
Ensure that option -Y also works for expression as it does for frame variable
Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value.
This is required for scenarios like this to work:
(lldb) p/x c
(Class) $0 = 0x0000000100adb7f8 NSObject
Previously this would say:
(lldb) p/x c
(Class) $0 = NSObject
ignoring the explicit format specifier
llvm-svn: 177893
Made the "--reverse" option to "source list" also be able to use the "--count". This helps us implement support for regexp source list command:
(lldb) l -10
Which gets turned into:
(lldb) source list --reverse --count 10
Also simplified the code that is used to track showing more source from the last file and line.
llvm-svn: 176961
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor
This fixes the loop (and consequent crash) by disposing of Crossref commands and related code
llvm-svn: 175831
- 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
(lldb) frame variable
without first launching the inferior, you get:
error: invalid frame
this is misleading and should probably hint that there is no process. Adding this flag makes sure that we get:
error: invalid process
The difference between eFlagRequiresProcess and eFlagProcessMustBeLaunched is an open question.
llvm-svn: 175702
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug
session.
<rdar://problem/12993641>
llvm-svn: 174793
Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x".
rdar://problem/13110464
llvm-svn: 174095
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
Providing a compact display mode for "po" to use where the convenience variable name and the pointer value are both hidden.
This is for convenience when dealing with ObjC instances where the description often gets it right and the debugger-provided information is not useful to most people.
If you need either of these, "expr" will still show them.
llvm-svn: 173748
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
Data formatters now cache themselves.
This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval.
Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization.
The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime.
Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type.
Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose.
llvm-svn: 173728
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
Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases
Where the old behavior would provide:
(lldb) mem read --format s `foo`
0x100000f5d: NULL
Now we do:
(lldb) mem read --format s `foo`
0x100000f5d: "hello world"
You can also specify a count and that many strings will be showed starting at the initial address:
(lldb) mem read -c 2 -f c-str `foo`
0x100000f1d: "hello world"
0x100000f29: "short"
llvm-svn: 173076
If there is any alive process being debugged, the user is asked for confirmation before quitting LLDB
This should prevent situations where the user mistakenly types "q" and LLDB slaughters their process without any mercy whatsoever
Since it can quickly get tedious, there is a new setting on the command interpreter to disable this and replicate the previous behavior
llvm-svn: 172757
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
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
Michael Sartain