| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Make it so that "b 245" should set a breakpoint at line 245 of the current file.
Also add a simple test file.
llvm-svn: 162419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to:
(lldb) b main
Breakpoint created: 1: name = 'main', locations = 1
Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to:
(lldb) settings set interpreter.expand-regex-aliases true
(lldb) b main
breakpoint set --name 'main'
Breakpoint created: 1: name = 'main', locations = 1
Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean).
Fixed auto completion for settings names when nothing has been type (it should show all settings).
llvm-svn: 162418
|
|
|
|
| |
llvm-svn: 162376
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads
Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".
llvm-svn: 162366
|
|
|
|
| |
llvm-svn: 162161
|
|
|
|
|
|
|
|
|
|
|
|
| |
could, during destruction,
tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter.
Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and
the InputReaderSP pertaining to the embedded python interpreter -- resulted from the
ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being
used by the PythonInputReaderManager instances.
llvm-svn: 162147
|
|
|
|
|
|
| |
Add 'watchpoint command add/delete/list' to lldb, plus two .py test files.
llvm-svn: 161638
|
|
|
|
|
|
|
|
|
| |
likely removed accidentally a while back.
The consequence occurred recently probably due to our swicth to build with c++11.
This fixed 3 test failures.
llvm-svn: 161625
|
|
|
|
|
|
| |
variable command which allows the user to provide a summary string with which he wants to display the variables without having to make a named summary first
llvm-svn: 161623
|
|
|
|
|
|
|
|
|
| |
and instead made us use implicit casts to bool.
This generated a warning in C++11.
<rdar://problem/11930775>
llvm-svn: 161559
|