| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
does not automatically initialize the script interpreter in order to transfer its output file handle to it
This should delay initialization of Python until strictly necessary and speed-up debugger startup
Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes
llvm-svn: 166967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit enables the new HasChildren() feature for synthetic children providers
Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call
Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly
Next steps are:
2) writing smart implementations of has_children for our providers whenever possible
3) make a test case
llvm-svn: 166495
|
| |
|
|
| |
llvm-svn: 166464
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
options:
- added help ("help language") listing the
possible options;
- added the possibility of synonyms for language
names, in this case "ObjC" for "Objective-C";
and
- made matching against language names case
insensitive.
This should improve discoverability.
<rdar://problem/12552359>
llvm-svn: 166457
|
| |
|
|
|
|
| |
help() pagination conflicts with our I/O management
llvm-svn: 166432
|
| |
|
|
|
|
|
|
|
|
|
| |
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
llvm-svn: 166426
|
| |
|
|
|
|
|
|
|
|
| |
Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header.
An example of sending a read register packet for the GPR on x86_64:
(lldb) process plugin packet send --command 0x07 --payload 0100000004000000
llvm-svn: 166346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at:
plugin
dynamic-loader
macosx-kernel
(bool) disable-kext-loading
To settings can be set using:
(lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true
I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.
llvm-svn: 166294
|
| |
|
|
|
|
|
|
| |
than "rb" and so weren't
finding the alias.
llvm-svn: 166249
|
| |
|
|
|
|
|
|
|
|
| |
Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:
settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py
Then run your program and see the extra threads.
llvm-svn: 166244
|
| |
|
|
|
|
|
|
|
|
| |
"expr" command and from
the SB API's that evaluate expressions.
<rdar://problem/12457211>
llvm-svn: 166062
|
| |
|
|
|
|
|
|
|
|
|
| |
I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
|
| |
|
|
| |
llvm-svn: 165808
|
| |
|
|
|
|
|
|
|
|
| |
with ~, we need to realpath it. Fixes the case where
settings set target.expr-prefix ~/lldb.prefix.header
wouldn't read this prefix header file. <rdar://problem/12475676>
llvm-svn: 165704
|
| |
|
|
|
|
| |
users should be able to override them with "unalias" but you can't unalias normal commands.
llvm-svn: 165630
|
| |
|
|
|
|
|
|
| |
if it exists rather than a generic but
not at all helpful message about not matching some unknown regex...
llvm-svn: 165349
|
| |
|
|
|
|
| |
it's too easy to type by mistake when typing "l" (read: I did this once).
llvm-svn: 165340
|
| |
|
|
| |
llvm-svn: 165330
|
| |
|
|
|
|
| |
our gdb friends.
llvm-svn: 165328
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CommandInterpreter::LoadCommandDictionary.
It is now a regex command alias that more faithfully emulates gdb's
behavior, most importantly, "bt 5" will backtrace 5 frames of the
currently selected thread. "bt all" still backtraces all threads
(unlike gdb) and for users who have learned to use "bt -c 5", that
form is still accepted.
llvm-svn: 165300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
to accessing a shared pointer without first checking for NULL
llvm-svn: 164950
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.
Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
Currently, the new API objects and features are not exposed via Python.
The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own
llvm-svn: 164865
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
zero-length hostname to be specified).
llvm-svn: 164752
|
| |
|
|
|
|
| |
conflict with it.
llvm-svn: 164737
|
| |
|
|
|
|
| |
kdp (darwin kernel) server with the new "gdb-remote" regex alias and "kdp-remote" regex alias commands.
llvm-svn: 164729
|
| |
|
|
|
|
| |
function not found error for a Python function in some cases where the function actually existed and had an empty docstring
llvm-svn: 164334
|
| |
|
|
|
|
| |
the same module where the target function is defined causes the help string not to come out
llvm-svn: 164172
|
| |
|
|
|
|
| |
Some platforms don't support this modification.
llvm-svn: 164148
|
| |
|
|
|
|
|
|
|
|
| |
This may (but shouldn't) break Linux (but I tested and it still worked on FreeBSD).
The same shell scripts are now used on Xcode and Makefiles, for generating
the SWIG bindings.
Some compatibility fixes were applied, too (python path, bash-isms, etc).
llvm-svn: 163912
|
| |
|
|
|
|
|
|
|
|
| |
"target image lookup" a bit better
documented by indicating that it takes
symbols OR functions.
<rdar://problem/12281325>
llvm-svn: 163839
|
| |
|
|
| |
llvm-svn: 163638
|
| |
|
|
|
|
| |
signature more compact and make it easy to 'just run an expression'
llvm-svn: 163239
|
| |
|
|
|
|
|
|
|
|
| |
the command line.
Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt.
Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function).
llvm-svn: 163043
|
| |
|
|
|
|
| |
return the data. This can end up being used to get the string contents of a text file and could end up not being NULL terminated. I added accessors to get the file contents raw, or with a null terminator. Added the needed calls to make this happen in the FileSpec and File classes.
llvm-svn: 162921
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 162679
|
| |
|
|
|
|
|
| |
Add 'attach <pid>|<process-name>' command to lldb, as well as 'detach' which is an alias of 'process detach'.
Add two completion test cases for "attach" and "detach".
llvm-svn: 162573
|
| |
|
|
|
|
| |
protocol.
llvm-svn: 162540
|
| |
|
|
|
|
|
|
| |
centralized the parsing of the string to encoding and string to generic register.
Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing.
llvm-svn: 162530
|
| |
|
|
| |
llvm-svn: 162527
|
| |
|
|
|
|
| |
fetch the data and convert it to C++ objects is still missing, but will come
llvm-svn: 162522
|
| |
|
|
|
|
| |
functionality (still WIP)
llvm-svn: 162513
|
| |
|
|
| |
llvm-svn: 162504
|
| |
|
|
| |
llvm-svn: 162503
|
| |
|
|
| |
llvm-svn: 162500
|
| |
|
|
|
|
| |
in a ref-counting and type-safe C++ API
llvm-svn: 162481
|
| |
|
|
|
|
| |
<rdar://problem/12161861>
llvm-svn: 162470
|