summaryrefslogtreecommitdiffstats
path: root/lldb/examples/python
Commit message (Collapse)AuthorAgeFilesLines
...
* Implemented a types.py module that allows types to be inspected for padding.Greg Clayton2013-06-191-0/+212
| | | | | | The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members. llvm-svn: 184364
* A few small enhancements to the diagnose-unwind command.Jason Molenda2013-06-191-24/+82
| | | | | | | | | | | | | | | | Change the simple-minded stack walk to not depend on lldb to unwind the first frame. Collect a list of Modules and Addresses seen while backtracing (with both methods), display the image list output for all of those modules, plus disassemble and image show-unwind any additional frames that the simple backtrace was able to unwind through instead of just the lldb unwind algorithm frames. Remove checks for older lldb's that didn't support -a for disassemble or specifying the assembler syntax on x86 targets. llvm-svn: 184280
* Small changes to diagnose_unwind. Correctly provide help text.Jason Molenda2013-06-051-6/+15
| | | | | | Print the lldb version at the top of the output. llvm-svn: 183289
* Adding a diagnose-nsstring commandEnrico Granata2013-05-302-1/+172
| | | | | | This should help us figure out issues with the NSString data formatter llvm-svn: 182972
* Providing a more interesting command template for LLDBEnrico Granata2013-05-091-25/+41
| | | | | | This one actually exploits the SB API to obtain information about your inferior process llvm-svn: 181500
* Adding some LLDB-specific logic to the tracer (in a separate tracer module) ↵Enrico Granata2013-05-071-12/+91
| | | | | | | | to improve the quality of the output when debugging data formatters (more improvements are necessary before this is really legible) llvm-svn: 181367
* First iteration of a Python tracer moduleEnrico Granata2013-05-071-0/+249
| | | | | | | | | | | | | | | | | | | This module uses Python's sys.settrace() mechanism so setup a hook that can log every significant operation This is a first step in providing a good debugging experience of Python embedded in LLDB This module comprises an OO infrastructure that wraps Python's tracing and inspecting mechanisms, plus a very simple logging tracer Output from this tracer looks like: call print_keyword_args from <module> @ 243 args are kwargs are {'first_name': 'John', 'last_name': 'Doe'} running print_keyword_args @ 228 locals are {'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} running print_keyword_args @ 229 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} first_name = John running print_keyword_args @ 228 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} running print_keyword_args @ 229 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} last_name = Doe running print_keyword_args @ 228 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} return from print_keyword_args value is None locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}} llvm-svn: 181343
* Print a backtrace line for a pc value even if we can't make an SBAddressJason Molenda2013-05-011-1/+2
| | | | | | out of it. llvm-svn: 180835
* Put a try/catch block around the SBAddress setting; don't want to Jason Molenda2013-04-301-13/+16
| | | | | | | terminate the command early if we happen to have an invalid load address. llvm-svn: 180826
* Rename unwind_diagnose.py to diagnose_unwind.py. ChangeJason Molenda2013-04-301-7/+7
| | | | | | | | | | | finish-swig-Python-LLDB.sh to create a new lldb.diagnose subdirectory in the LLDB framework; the first diagnostic command in this directory is diagnose-unwind. There may be others added in the future. Users can load these diagnostic tools into their session with "script import lldb.diagnose". llvm-svn: 180768
* Remove a print statement that was left in accidentally.Greg Clayton2013-04-241-1/+0
| | | | llvm-svn: 180223
* One line I forgot to remove.Jason Molenda2013-04-231-1/+0
| | | | llvm-svn: 180086
* Update the unwind_diagnose script to work correctly with bothJason Molenda2013-04-231-48/+10
| | | | | | | | | | | lldb-179 version numberings and the new lldb-300 version numberings. Remove the pretense that someone might run this from the command line; this is only used from within a live lldb debug session. Fix the loading so it can be loaded via "script import lldb.macosx" or the script can be loaded individually like "command script import unwind_diagnose.py" llvm-svn: 180085
* Add a new -a / --address argument to image show-unwind to get theJason Molenda2013-04-231-1/+4
| | | | | | | | | | | 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
* Add a new python file to help diagnose backtrace failures in the field.Jason Molenda2013-04-231-0/+197
| | | | | | | | | | | | | | | It will be installed in the LLDB.framework and can be loaded with (lldb) script import lldb.macosx after which a "unwind-diagnose" command will be registered. Select the thread which has a bad backtrace and run this command -- a lot of information about the stack frames, and an alternate backtrace algorithm, will be used. The information will often be sufficient for a remote person to figure out why the backtrace failed. <rdar://problem/13679300> llvm-svn: 180077
* <rdar://problem/13477795>Greg Clayton2013-04-042-3/+10
| | | | | | crashlog.py was always subtracting 1 to point to the previous instruction when symbolicating ARM backtraces. Many times the backtraces will include bit zero set to 1 to indicate thumb, so we need to make sure we mask the address and then backup one for non frame zero frames. llvm-svn: 178812
* Playing around with making performance test cases run from within python. Greg Clayton2013-04-031-25/+122
| | | | llvm-svn: 178708
* A few more tweaks to the python perf tests. Now there is a MemoryMeasurement.Greg Clayton2013-03-261-19/+60
| | | | llvm-svn: 178069
* Added a python version of the performance tests. It will be good to see if ↵Greg Clayton2013-03-231-0/+197
| | | | | | the overhead of python interferes at all with our performance readings. We can try things out with this script and see how things go. llvm-svn: 177811
* Created a sample "jump" command that handlesSean Callanan2013-03-121-0/+173
| | | | | | | GDB-style linespecs. This command allows changing the PC without manually looking up the new address. llvm-svn: 176841
* Initial checkin of a new project: LLDB Performance Testing InfrastructureEnrico Granata2013-03-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a very basic implementation of a library that easily allows to drive LLDB.framework to write test cases for performance This is separate from the LLDB testsuite in test/ in that: a) this uses C++ instead of Python to avoid measures being affected by SWIG b) this is in very early development and needs lots of tweaking before it can be considered functionally complete c) this is not meant to test correctness but to help catch performance regressions There is a sample application built against the library (in darwin/sketch) that uses the famous sample app Sketch as an inferior to measure certain basic parameters of LLDB's behavior. The resulting output is a PLIST much like the following: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <dict> <key>fetch-frames</key> <real>0.13161715522222225</real> </dict> <dict> <key>file-line-bkpt</key> <real>0.029111678750000002</real> </dict> <dict> <key>fetch-modules</key> <real>0.00026376766666666668</real> </dict> <dict> <key>fetch-vars</key> <real>0.17820429311111111</real> </dict> <dict> <key>run-expr</key> <real>0.029676525769230768</real> </dict> </array> </plist> Areas for improvement: - code cleanups (I will be out of the office for a couple days this coming week, but please keep ideas coming!) - more metrics and test cases - better error checking This toolkit also comprises a simple event-loop-driven controller for LLDB, similar yet much simpler to what the Driver does to implement the lldb command-line tool. llvm-svn: 176715
* Added a new module that can dump all line tables for all compile units in ↵Greg Clayton2013-03-071-0/+59
| | | | | | | | any modules that are specified as arguments to the "dump_module_line_tables" command. I used this to verify that the debug map line tables were the same as previous LLDB releases prior to my change in the DWARF in .o file linking. llvm-svn: 176610
* Being explicit about how ignoring optparse's exceptions is not a best principleEnrico Granata2013-02-251-0/+2
| | | | llvm-svn: 176059
* Added missing lldb module namespace.Greg Clayton2013-02-251-1/+1
| | | | llvm-svn: 176049
* <rdar://problem/13286937> Greg Clayton2013-02-251-3/+13
| | | | | | Make sure to not look in self.images when we have a symbolicator with a live process. llvm-svn: 176040
* Mark the command as failed if parsing fails.Jim Ingham2013-02-211-0/+1
| | | | llvm-svn: 175776
* <rdar://problem/13069948>Greg Clayton2013-01-251-1/+2
| | | | | | | | | | | | 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
* <rdar://problem/13010007>Greg Clayton2013-01-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method: class OperatingSystemPlugin: def create_thread(self, tid, context): # Return a dictionary for a new thread to create it on demand This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used. Cleaned up the code in PythonDataObjects.cpp/h: - renamed all classes that started with PythonData* to be Python*. - renamed PythonArray to PythonList. Cleaned up the code to use inheritance where - Centralized the code that does ref counting in the PythonObject class to a single function. - Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object. - Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form: - PyObject * - const PythonObject & - const lldb::ScriptInterpreterObjectSP & Cleaned up code in ScriptInterpreterPython: - Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time. - Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized. llvm-svn: 172873
* Made crashlog.py handle cases where a parentSean Callanan2013-01-121-3/+5
| | | | | | | | | process's name contains spaces. Thanks to Justin Seyster for the patch. <rdar://problem/13002540> llvm-svn: 172294
* Updated documentation on the "register_data_addr" key that can be supplied ↵Greg Clayton2013-01-091-0/+5
| | | | | | in the "thread" dictionary return value for the python OS plug-ins. llvm-svn: 171934
* Allow operating system plug-ins to specify the address for registers so we ↵Greg Clayton2012-10-251-1/+1
| | | | | | don't have to create data up front. llvm-svn: 166701
* <rdar://problem/12491420>Greg Clayton2012-10-181-1/+1
| | | | | | | | | | 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
* Added process attach options and also use the SBLaunchInfo and SBAttachInfo.Greg Clayton2012-09-251-14/+72
| | | | llvm-svn: 164619
* Added auto LLDB import to the crashlog script.Greg Clayton2012-09-191-2/+32
| | | | llvm-svn: 164192
* Modified the command template to include best practices.Greg Clayton2012-09-131-17/+24
| | | | llvm-svn: 163773
* Added some documentation and an accessor for the target with an explanation ↵Greg Clayton2012-09-121-1/+21
| | | | | | of why to not use "lldb.target". llvm-svn: 163671
* Print the stack size followed by the full stack info.Greg Clayton2012-09-111-2/+2
| | | | llvm-svn: 163589
* Added a python example that will compute which functions in a process are ↵Greg Clayton2012-09-101-0/+56
| | | | | | hogging the stack. llvm-svn: 163543
* Added a quick example to show how disasembly output can be customized.Greg Clayton2012-09-071-0/+24
| | | | llvm-svn: 163421
* Make the tab character in the thread frame lines optional.Jason Molenda2012-08-311-1/+1
| | | | llvm-svn: 163037
* Added command lists that can be executed on launch, stop, crash and exit. ↵Greg Clayton2012-08-311-15/+71
| | | | | | Added code to auto import the lldb module that we can use on many stand alone modules. llvm-svn: 162972
* Added an example that show correct usage of the async process event API.Greg Clayton2012-08-311-0/+139
| | | | llvm-svn: 162967
* <rdar://problem/11757916>Greg Clayton2012-08-292-6/+23
| | | | | | | | | | | | 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
* Instead of using re.split and requiring two spaces between the "regname: ↵Jason Molenda2012-08-281-1/+2
| | | | | | | | | regvalue" pairs, use re.findall and specify the regexp of regname: regvalue that we're interested in. <rdar://problem/12188752> llvm-svn: 162806
* The OS plug-in can now get data from a python script that implements the ↵Greg Clayton2012-08-241-3/+4
| | | | | | protocol. llvm-svn: 162540
* We have a partially working OS plug-in through python!Greg Clayton2012-08-241-6/+8
| | | | llvm-svn: 162532
* Fixing an issue in the OS sampleEnrico Granata2012-08-241-0/+1
| | | | llvm-svn: 162531
* Added Args::StringForEncoding(), Args::StringToGenericRegister() and ↵Greg Clayton2012-08-241-0/+63
| | | | | | | | 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
* Added qVAttachOrWaitSupported packet support.Greg Clayton2012-08-201-0/+1
| | | | llvm-svn: 162207
* <rdar://problem/12087275>Greg Clayton2012-08-131-1/+1
| | | | | | Make the crashlog parser able to deal with spaces in the process name. llvm-svn: 161772
OpenPOWER on IntegriCloud