| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
coherence with the rest of the LLDB command-line interface
llvm-svn: 184147
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Allow memory read -t to take persistent types (those defined with expression struct $....)
llvm-svn: 183766
|
|
|
|
|
|
| |
the byte size will tell us how to display it.
llvm-svn: 183755
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 182873
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 182325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://problem/13916722
llvm-svn: 182068
|
|
|
|
|
|
| |
"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
|
|
|
|
|
|
| |
value and if that value is False, LLDB won’t stop at the breakpoint
llvm-svn: 182059
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
print "//mach_kernel" if you are debugging an executable
in the top level directory.
llvm-svn: 181190
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
TestPlatformCommand failing on buildbot.
llvm-svn: 180963
|
|
|
|
|
|
| |
compute.
llvm-svn: 180898
|
|
|
|
| |
llvm-svn: 180868
|
|
|
|
|
|
|
|
|
|
| |
process plugin (or in the
case of ProcessGDBRemote the stub we are talking to) know how to do that.
rdar://problem/13680832
llvm-svn: 180831
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
“plugin load” tries to be more helpful when it fails to load a plugin
llvm-svn: 180218
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 179892
|
|
|
|
|
|
| |
the macros and just use C++11.
llvm-svn: 179805
|
|
|
|
|
|
| |
Fixed an issue where "platform process list" help message has options displayed a couple dozen times.
llvm-svn: 179792
|
|
|
|
|
|
| |
Disable "source info" until actually implemented.
llvm-svn: 179787
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
expression hits a breakpoint.
llvm-svn: 179133
|
|
|
|
| |
llvm-svn: 179110
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://problem/13536544
llvm-svn: 178367
|