summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/interface/SBThread.i
Commit message (Collapse)AuthorAgeFilesLines
* LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and ↵Kuba Brecka2014-10-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | report data extraction Reviewed at http://reviews.llvm.org/D5592 This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API. More precisely this patch... adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable adds a collection of these plugins into the Process class AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now) SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream adds a test case for all of this I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose. Kuba llvm-svn: 219546
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-0/+3
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Fix typos.Bruce Mitchener2014-07-011-1/+1
| | | | llvm-svn: 212132
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done. This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression. I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData. I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included. A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite. Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub. The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages. I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread. I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably. Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use. I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result. llvm-svn: 210874
* Add a new SBThread::SafeToCallFunctions API; this calls over toJason Molenda2014-05-131-0/+10
| | | | | | | | | | the SystemRuntime to check if a thread will have any problems performing an inferior function call so the driver can skip making that function call on that thread. Often the function call can be executed on another thread instead. <rdar://problem/16777874> llvm-svn: 208732
* Add a new SBThread::GetQueue() method to get the queue that is Jason Molenda2014-04-251-0/+13
| | | | | | | | | | currently associated with a given thread, on relevant targets. Change the queue detection code to verify that the queues associated with all live threads are included in the list. <rdar://problem/16411314> llvm-svn: 207160
* Change the Mac OS X SystemRuntime plugin from using the placeholderJason Molenda2014-02-051-0/+19
| | | | | | | | | | | | | | libldi library to collect extended backtrace information; switch to the libBacktraceRecording library and its APIs. Complete the work of adding QueueItems to Queues and allow for the QueueItems to be interrogated about their extended backtraces in turn. There's still cleanup and documentation to do on this code but the code is functional and I it's a good time to get the work-in-progress checked in. <rdar://problem/15314027> llvm-svn: 200822
* Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() methodJason Molenda2013-11-161-1/+13
| | | | | | | | | | (and same thing to Thread base class) which can be used when looking at an ExtendedBacktrace thread; it will try to find the IndexID() of the original thread that was executing this backtrace when it was recorded. If lldb can't find a record of that thread, it will return the same value as IndexID() for the ExtendedBacktrace thread. llvm-svn: 194912
* Change SBThread::GetExtendedBacktrace toJason Molenda2013-11-121-2/+2
| | | | | | | SBThread::GetExtendedBacktraceThread to make it more clear what is being returned. llvm-svn: 194531
* Rename extended backtrace methods to take out the "ThreadOrigin"Jason Molenda2013-11-061-2/+2
| | | | | | | bit from the method names. <rdar://problem/15314369> llvm-svn: 194122
* Add a new GetThreadOriginExtendedBacktrace method to the Jason Molenda2013-11-061-0/+13
| | | | | | | SystemRuntime and SBThread classes. <rdar://problem/15314369> llvm-svn: 194111
* Add the GetNumThreadOriginExtendedBacktraceTypes andJason Molenda2013-11-051-0/+10
| | | | | | | | | | | GetThreadOriginExtendedBacktraceTypeAtIndex methods to SBProcess. Add documentation for the GetQueueName and GetQueueID methods to SBThread. <rdar://problem/15314369> llvm-svn: 194063
* Fix for a mistake spotted by Enrico with the SBThread::queue_id accessor.Jason Molenda2013-10-221-1/+1
| | | | llvm-svn: 193136
* Expose the Thread::GetQueueID() method through the SBThread API, similar toJason Molenda2013-10-211-0/+6
| | | | | | the existing SBThread::GetQueueName() method. llvm-svn: 193132
* Add missing GetBroadcasterClassName and event types enum to SBThread.iDaniel Malea2013-10-031-0/+16
| | | | llvm-svn: 191933
* Added a 'jump' command, similar to GDBs.Richard Mitton2013-09-121-2/+5
| | | | | | | | | This allows the PC to be directly changed to a different line. It's similar to the example python script in examples/python/jump.py, except implemented as a builtin. Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function) llvm-svn: 190572
* <rdar://problem/11742979>Enrico Granata2013-05-031-0/+6
| | | | | | | | | SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-) Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both llvm-svn: 180987
* Adding new Python API function to check for stopped threads.Andrew Kaylor2013-04-151-0/+6
| | | | llvm-svn: 179577
* Fixed a few bugs in the "step in" thread plan logic.Jim Ingham2012-12-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added a "step-in-target" flag to "thread step-in" so if you have something like: Process 28464 stopped * thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1 frame #0: 0x0000000100000e08 a.out`main at main.c:62 61 -> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint. 63 and you want to get into "complex" skipping a, b and c, you can do: (lldb) step -t complex Process 28464 stopped * thread #1: tid = 0x1c03, function: complex , stop reason = step in frame #0: 0x0000000100000d0d a.out`complex at main.c:44 41 42 int complex (int first, int second, int third) 43 { -> 44 return first + second + third; // Step in targetting complex should stop here 45 } 46 47 int main (int argc, char const *argv[]) llvm-svn: 170008
* <rdar://problem/12649160>Greg Clayton2012-12-051-0/+1
| | | | | | Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-101-0/+12
| | | | | | | | | | | | | ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP. Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame changes the stack. Made the Driver use this notification to print the new thread status rather than doing it in the command. Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call. <rdar://problem/12383087> llvm-svn: 165640
* Make the unwinding of the stack part of "thread return" work, and add the ↵Jim Ingham2012-09-141-1/+1
| | | | | | thread return command. llvm-svn: 163867
* Start at getting "thread return" working. Doesn't work yet.Jim Ingham2012-09-121-0/+3
| | | | llvm-svn: 163670
* Add accessors on process to get & set the selected thread by IndexID (useful ↵Jim Ingham2012-07-131-0/+6
| | | | | | since that's the one that "thread list" shows and it won't get reused even if the underlying system thread ID gets reused. llvm-svn: 160187
* Added documentation for many of our python properties and also made the ↵Greg Clayton2012-06-291-11/+11
| | | | | | property help show up by declaring the properties correctly. We previosly declared properties into a local "x" variable, what I didn't realize is that the help will use this as the property name for the help output. llvm-svn: 159468
* Make every Python API __len__() method return a PyIntObject.Filipe Cabecinhas2012-05-111-1/+1
| | | | | | | swig 2.0+ seems to default to using PyLongObjects, but the __len__() method _must_ return a PyIntObject. llvm-svn: 156639
* Cleaned up the documentation strings for many helper objects and addedGreg Clayton2012-02-031-7/+7
| | | | | | lldb.SBModule.section and lldb.SBModule.sections property access. llvm-svn: 149665
* Added many more python convenience accessors:Greg Clayton2012-02-011-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | You can now access a frame in a thread using: lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread Where "int" is an integer index. You can also access a list object with all of the frames using: lldb.SBThread.frames => list() of lldb.SBFrame objects All SB objects that give out SBAddress objects have properties named "addr" lldb.SBInstructionList now has the following convenience accessors for len() and instruction access using an index: insts = lldb.frame.function.instructions for idx in range(len(insts)): print insts[idx] Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key: pc_inst = lldb.frame.function.instructions[lldb.frame.addr] lldb.SBProcess now exposes: lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive lldb.SBProcess.is_running => BOOL check if a process is running (or stepping): lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed: lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process SBInstruction now exposes: lldb.SBInstruction.mnemonic => python string for instruction mnemonic lldb.SBInstruction.operands => python string for instruction operands lldb.SBInstruction.command => python string for instruction comment SBModule now exposes: lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str" lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex lldb.SBModule.symbols => list() of all symbols in a module SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr" property. The current "lldb.target" will be used to try and resolve the load address. Load addresses can also be set using this accessor: addr = lldb.SBAddress() addd.load_addr = 0x123023 Then you can check the section and offset to see if the address got resolved. SBTarget now exposes: lldb.SBTarget.module[int] => lldb.SBModule from zero based module index lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target SBSymbol now exposes: lldb.SBSymbol.name => python string for demangled symbol name lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none lldb.SBSymbol.type => lldb.eSymbolType enum value lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one) lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol (if there is one) lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol SBFunction now also has these new properties in addition to what is already has: lldb.SBFunction.addr => SBAddress object that represents the start address for this function lldb.SBFunction.end_addr => SBAddress for the end address of the function lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function SBFrame now exposes the SBAddress for the frame: lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC These are all in addition to what was already added. Documentation and website updates coming soon. llvm-svn: 149489
* Added a new convenience property on lldb.SBThread names "frames" which ↵Greg Clayton2012-02-011-0/+10
| | | | | | | | | | | | | always returns a complete list of all lldb.SBFrame objects: (lldb) script >>> frames = lldb.thread.frames >>> for frame in frames: ... print frame Also changed all of the "__repr__" methods to strip any trailing newline characters so we don't end up with entra newlines. llvm-svn: 149466
* Added the ability to get the target triple, byte order and address byte sizeGreg Clayton2012-01-291-0/+30
| | | | | | | from the SBTarget and SBModule interfaces. Also added many python properties for easier access to many things from many SB objects. llvm-svn: 149191
* Fix Python docstring for SBThread.GetStopDescription().Johnny Chen2011-12-191-0/+4
| | | | llvm-svn: 146890
* Fixed code rot pointed out by Jim.Johnny Chen2011-12-171-1/+1
| | | | | | SBThread::GetStopReasonDataCount/GetStopReasonDataAtIndex() need to handle eStopReasonWatchpoint. llvm-svn: 146812
* Add the ability to capture the return value in a thread's stop info, and ↵Jim Ingham2011-12-171-0/+3
| | | | | | | | | | | | | print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
* Add SWIG Python interface files for SBProcess, SBThread, and SBFrame.Johnny Chen2011-07-181-0/+171
llvm-svn: 135419
OpenPOWER on IntegriCloud