summaryrefslogtreecommitdiffstats
path: root/lldb/scripts
Commit message (Collapse)AuthorAgeFilesLines
* Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham2012-02-166-0/+24
| | | | | | | | | class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
* <rdar://problem/10062621>Enrico Granata2012-02-1510-0/+636
| | | | | | | | | | | | | | | | | | New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
* Brought LLVM/Clang up to top of tree. The onlySean Callanan2012-02-091-2/+2
| | | | | | | | change (besides logging) is that now string literals in the IR are ConstantDataArrays instead of ConstantArrays. llvm-svn: 150142
* Send Breakpoint Changed events for all the relevant changes to breakpoints.Jim Ingham2012-02-082-0/+9
| | | | | | | Also, provide and use accessors for the thread options on breakpoints so we can control sending the appropriate events. llvm-svn: 150057
* Removed all of the "#ifndef SWIG" from the SB header files since we are usingGreg Clayton2012-02-067-37/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. llvm-svn: 149853
* <rdar://problem/10560053>Greg Clayton2012-02-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". llvm-svn: 149804
* I have brought LLDB up-to-date with top of treeSean Callanan2012-02-0410-454/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM/Clang. This brings in several fixes, including: - Improvements in the Just-In-Time compiler's allocation of memory: the JIT now allocates memory in chunks of sections, improving its ability to generate relocations. I have revamped the RecordingMemoryManager to reflect these changes, as well as to get the memory allocation and data copying out fo the ClangExpressionParser code. Jim Grosbach wrote the updates to the JIT on the LLVM side. - A new ExternalASTSource interface to allow LLDB to report accurate structure layout information to Clang. Previously we could only report the sizes of fields, not their offsets. This meant that if data structures included field alignment directives, we could not communicate the necessary alignment to Clang and accesses to the data would fail. Now we can (and I have update the relevant test case). Thanks to Doug Gregor for implementing the Clang side of this fix. - The way Objective-C interfaces are completed by Clang has been made consistent with RecordDecls; with help from Doug Gregor and Greg Clayton I have ensured that this still works. - I have eliminated all local LLVM and Clang patches, committing the ones that are still relevant to LLVM and Clang as needed. I have tested the changes extensively locally, but please let me know if they cause any trouble for you. llvm-svn: 149775
* Allow a SBAddress to be created from a SBSection and an offset.Greg Clayton2012-02-043-3/+15
| | | | | | | | Changed the lldb.SBModule.section[<str>] property to return a single section. Added a lldb.SBSection.addr property which returns an lldb.SBAddress object. llvm-svn: 149755
* Convert all python objects in our API to use overload the __str__ methodGreg Clayton2012-02-041-55/+79
| | | | | | | | | | | | | | | | instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
* Expose more convenience functionality in the python classes.Greg Clayton2012-02-034-0/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb.SBValueList now exposes the len() method and also allows item access: lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches) lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches lldb.SBFrame now exposes: lldb.SBFrame.variables => SBValueList of all variables that are in scope lldb.SBFrame.vars => see lldb.SBFrame.variables lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame lldb.SBFrame.args => see lldb.SBFrame.arguments lldb.SBFrame.statics => SBValueList of all static variables lldb.SBFrame.registers => SBValueList of all registers for the current frame lldb.SBFrame.regs => see lldb.SBFrame.registers Combine any of the above properties with the new lldb.SBValueList functionality and now you can do: y = lldb.frame.vars['rect.origin.y'] or vars = lldb.frame.vars for i in range len(vars): print vars[i] Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path for any variable or child within the variable. This makes it easier to get a value from the current frame like "rect.origin.y". The resulting value is also not a constant result as expressions will return, but a live value that will continue to track the current value for the variable expression path. lldb.SBValue now exposes: lldb.SBValue.unsigned => unsigned integer for the value lldb.SBValue.signed => a signed integer for the value llvm-svn: 149684
* Fixed casting in the lldb::SBValue::Cast(SBType) function.Greg Clayton2012-02-031-1/+17
| | | | llvm-svn: 149673
* Cleaned up the documentation strings for many helper objects and addedGreg Clayton2012-02-034-26/+79
| | | | | | lldb.SBModule.section and lldb.SBModule.sections property access. llvm-svn: 149665
* Added support to SBType for getting template arguments from a SBType:Greg Clayton2012-02-031-0/+9
| | | | | | | | | | | | | | | | | | uint32_t SBType::GetNumberOfTemplateArguments (); lldb::SBType SBType::GetTemplateArgumentType (uint32_t idx); lldb::TemplateArgumentKind SBType::GetTemplateArgumentKind (uint32_t idx); Some lldb::TemplateArgumentKind values don't have a corresponding SBType that will be returned from SBType::GetTemplateArgumentType(). This will help our data formatters do their job by being able to find out the type of template params and do smart things with those. llvm-svn: 149658
* ensure that changes to the typemaps are properly detected and cause SWIG to ↵Enrico Granata2012-02-021-0/+14
| | | | | | rebuild LLDBWrapPython.cpp llvm-svn: 149606
* When outputting hex values use unsigned integer values so we don't getGreg Clayton2012-02-021-2/+7
| | | | | | | negative hex values. Also added a very rudimentary version of the == and != operators to the lldb.value helper class. llvm-svn: 149564
* Added many more python convenience accessors:Greg Clayton2012-02-0113-8/+361
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-012-26/+192
| | | | | | | | | | | | | 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 a new class to the lldb python module:Greg Clayton2012-02-011-0/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | lldb.value() It it designed to be given a lldb.SBValue object and it allows natural use of a variable value: pt = lldb.value(lldb.frame.FindVariable("pt")) print pt print pt.x print pt.y pt = lldb.frame.FindVariable("rectangle_array") print rectangle_array[12] print rectangle_array[5].origin.x Note that array access works just fine and works on arrays or pointers: pt = lldb.frame.FindVariable("point_ptr") print point_ptr[5].y Also note that pointer child accesses are done using a "." instead of "->": print point_ptr.x llvm-svn: 149464
* Added fuzz testing for when we call API calls with an invalid object.Greg Clayton2012-01-311-0/+2
| | | | | | | | | We previously weren't catching that SBValue::Cast(...) would crash if we had an invalid (empty) SBValue object. Cleaned up the SBType API a bit. llvm-svn: 149447
* This commit provides a new default summary for Objective-C boolean ↵Enrico Granata2012-01-311-0/+15
| | | | | | variables, which shows YES or NO instead of the character value. A new category named objc is added to contain this summary provider. Any future Objective-C related formatters would probably fit here llvm-svn: 149388
* Removed the "lldb-forward-rtti.h" header file as it was designed to containGreg Clayton2012-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | all RTTI types, and since we don't use RTTI anymore since clang and llvm don't we don't really need this header file. All shared pointer definitions have been moved into "lldb-forward.h". Defined std::tr1::weak_ptr definitions for all of the types that inherit from enable_shared_from_this() in "lldb-forward.h" in preparation for thread hardening our public API. The first in the thread hardening check-ins. First we start with SBThread. We have issues in our lldb::SB API right now where if you have one object that is being used by two threads we have a race condition. Consider the following code: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 if (m_opaque_sp) 6 { 7 result = m_opaque_sp->DoSomething(); 8 } 9 return result; 10 } And now this happens: Thread 1 enters any SBThread function and checks its m_opaque_sp and is about to execute the code on line 7 but hasn't yet Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear() and clears the contents of the shared pointer member Thread 1 now crashes when it resumes. The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this function would look like: 1 int 2 SBThread::SomeFunction() 3 { 4 int result = -1; 5 ThreadSP thread_sp(m_opaque_wp.lock()); 6 if (thread_sp) 7 { 8 result = m_opaque_sp->DoSomething(); 9 } 10 return result; 11 } Now we have a solid thread safe API where we get a local copy of our thread shared pointer from our weak_ptr and then we are guaranteed it can't go away during our function. So lldb::SBThread has been thread hardened, more checkins to follow shortly. llvm-svn: 149218
* Removed an incorrectly added property from SBTarget.iGreg Clayton2012-01-291-3/+0
| | | | llvm-svn: 149192
* Added the ability to get the target triple, byte order and address byte sizeGreg Clayton2012-01-2916-0/+455
| | | | | | | from the SBTarget and SBModule interfaces. Also added many python properties for easier access to many things from many SB objects. llvm-svn: 149191
* <rdar://problem/10750012>Greg Clayton2012-01-271-8/+0
| | | | | | | | Remove a pseudo terminal master open and slave file descriptor that was being used for pythong stdin. It was not hooked up correctly and was causing file descriptor leaks. llvm-svn: 149098
* If timestamps are enabled when logging GDB remote packets ("log enable -T -f ↵Greg Clayton2012-01-251-2/+97
| | | | | | | | | | | | | | | | | | | | | | | /tmp/packets.log gdb-remote logs") then get the amount of time spent executing each packet and summarize at the end of a dump. Sample timing output looks like: ---------------------------------------------------------------------- Packet timing summary: ---------------------------------------------------------------------- Packet Time % ---------------------- -------- ------ qThreadStopInfo 0.363844 35.35 m 0.281967 27.39 s 0.147160 14.30 qfThreadInfo 0.070865 6.88 qsThreadInfo 0.061608 5.99 z 0.036796 3.57 Z 0.036271 3.52 c 0.018410 1.79 H 0.012418 1.21 ---------------------- -------- ------ Total 1.029339 100.00 llvm-svn: 148983
* Handle 's' packets correctly when disassembling GDB packet output.Greg Clayton2012-01-251-5/+15
| | | | llvm-svn: 148911
* Integrated a patch for the MCJIT that inhibitsSean Callanan2012-01-191-0/+12
| | | | | | a memory leak. llvm-svn: 148507
* Patch from Enrico Granata that moves SBData related functions into the SBDataGreg Clayton2012-01-072-21/+46
| | | | | | | class instead of requiring a live process in order to be able to create useful SBData objects. llvm-svn: 147702
* http://llvm.org/bugs/show_bug.cgi?id=11619Johnny Chen2012-01-062-0/+172
| | | | | | | | Allow creating SBData values from arrays or primitives in Python Patch submitted by Enrico Granata. llvm-svn: 147639
* Fixed a problem in our local Clang's method forSean Callanan2012-01-051-0/+19
| | | | | | | | | | | | performing Objective-C instance variable lookup. Previously, it only completed the derived class that was the beginning of the search. Now, as it walks up the superclass chain looking for the ivar, it completes each superclass in turn. Also added a testcase covering this issue. llvm-svn: 147621
* <rdar://problem/10507811>Greg Clayton2012-01-041-4/+5
| | | | | | | | | | Be better at detecting when DWARF changes and handle this more gracefully than asserting and exiting. Also fixed up a bunch of system calls that weren't properly checking for EINTR. llvm-svn: 147559
* Cleaned up the usage to show the BuildAndIntegration configuration.Greg Clayton2011-12-281-3/+3
| | | | llvm-svn: 147325
* The "desired result type" code in the expressionSean Callanan2011-12-211-0/+25
| | | | | | | | | | | | | | | | | | | | | | parser has hitherto been an implementation waiting for a use. I have now tied the '-o' option for the expression command -- which indicates that the result is an Objective-C object and needs to be printed -- to the ExpressionParser, which communicates the desired type to Clang. Now, if the result of an expression is determined by an Objective-C method call for which there is no type information, that result is implicitly cast to id if and only if the -o option is passed to the expression command. (Otherwise if there is no explicit cast Clang will issue an error. This behavior is identical to what happened before r146756.) Also added a testcase for -o enabled and disabled. llvm-svn: 147099
* Tightened Clang against a bug in which RecordDeclsSean Callanan2011-12-211-0/+14
| | | | | | | | with incomplete definition data were being converted. Now Clang attempts to complete RecordDecls before converting them, avoiding a nasty crash. llvm-svn: 147029
* Add needed Clear methods.Jim Ingham2011-12-193-0/+9
| | | | | | <rdar://problem/10596340> llvm-svn: 146902
* 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
* Added a version of the LLVM/Clang checkout andSean Callanan2011-12-171-0/+73
| | | | | | | build script that applies any local patches to LLVM/Clang. llvm-svn: 146811
* 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
* I have added a new patch to LLVM that makes theSean Callanan2011-12-171-0/+199
| | | | | | | | | | | enhanced disassembler classify disassemblers by target triple (as a string) rather than just by the architecture component of the triple. This fixes a problem where different variants of the Thumb instruction set were lumped into the same hash bucket. llvm-svn: 146799
* Updated Clang to take an enhancement to the waySean Callanan2011-12-163-12/+12
| | | | | | | | | | | | | | we handle Objective-C method calls. Currently, LLDB treats the result of an Objective-C method as unknown if the type information doesn't have the method's signature. Now Clang can cast the result to id if it isn't explicitly cast. I also added a test case for this, as well as a fix for a type import problem that this feature exposed. llvm-svn: 146756
* Add fuzz calls for newly added SBProcess methods. Fix a typo in the audodoc ↵Johnny Chen2011-12-151-1/+1
| | | | | | of SBProcess.ReadCStringFromMemory(). llvm-svn: 146695
* <rdar://problem/10584789>Greg Clayton2011-12-151-0/+3
| | | | | | | | | | Added a static memory pressure function in SBDebugger: void SBDebugger::MemoryPressureDetected () This can be called by applications that detect memory pressure to cause LLDB to release cached information. llvm-svn: 146640
* Expose new read memory fucntion through python in SBProcess:Greg Clayton2011-12-151-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
* I have added a function to SBTarget that allowsSean Callanan2011-12-142-16/+37
| | | | | | | | | | | | | | | clients to disassemble a series of raw bytes as demonstrated by a new testcase. In the future, this API will also allow clients to provide a callback that adds comments for addresses in the disassembly. I also modified the SWIG harness to ensure that Python ByteArrays work as well as strings as sources of raw data. llvm-svn: 146611
* Add more robustness - use PyString_CheckExact(pvalue) to check whether ↵Johnny Chen2011-12-141-1/+1
| | | | | | | | pvalue is a Python string before calling PyString_AsString(pvalue). Similar to http://llvm.org/viewvc/llvm-project?rev=146584&view=rev. llvm-svn: 146606
* http://llvm.org/bugs/show_bug.cgi?id=11569Johnny Chen2011-12-141-2/+4
| | | | | | | | | | LLDBSwigPythonCallCommand crashes when a command script returns an object Add more robustness to LLDBSwigPythonCallCommand. It should check whether the returned Python object is a string, and only assign it as the error msg when the check holds. Also add a regression test. llvm-svn: 146584
* Add SBValue::GetDynamicValue and SBValue::GetStaticValue API's.Jim Ingham2011-12-081-0/+9
| | | | | | <rdar://problem/10545069> llvm-svn: 146173
* Picked up a new revision of Clang to pull in Objective-CSean Callanan2011-12-015-13/+13
| | | | | | | | | | | | | | | | | enhancements. With these enhancements, the return values of Objective-C methods with unknown return types can be implicitly cast to id for the purpose of making method calls. So what would have required this: (int)[(id)[ClassWithNoDebugInfo methodReturningObject] methodReturningInt] can now be written as: (int)[[ClassWithNoDebugInfo methodReturningObject] methodReturningInt] llvm-svn: 145567
* SBProcess.PutSTDIN() needs to be properly typemapped when swigging,Johnny Chen2011-11-283-0/+15
| | | | | | | | | | | | | | | | | so that we can do Python scripting like this: target = self.dbg.CreateTarget(self.exe) self.dbg.SetAsync(True) process = target.LaunchSimple(None, None, os.getcwd()) process.PutSTDIN("Line 1 Entered.\n") process.PutSTDIN("Line 2 Entered.\n") process.PutSTDIN("Line 3 Entered.\n") Add TestProcessIO.py to exercise the process IO API: PutSTDIN()/GetSTDOUT()/GetSTDERR(). llvm-svn: 145282
OpenPOWER on IntegriCloud