summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/LanguageRuntime/ObjC
Commit message (Collapse)AuthorAgeFilesLines
...
* Thinned the AppleObjCRuntimeV2's class descriptors.Sean Callanan2012-10-091-232/+118
| | | | | | | | | | | | | | | | | | | | | The following are now derived lazily: - The name of the class (cached); - the instance size of the class (not cached); The following have been removed entirely: - Whether the class is realized. This is an implementation detail. - The contents of the objc_class object. That object can be read as needed. - Whether the class is valid. The fact that we vended a class to begin with means it's valid. We will only give up looking parts of it up if they are not in the format we expect. llvm-svn: 165567
* Cleanup in the AppleObjCRuntimeV2 to make descriptorsSean Callanan2012-10-092-29/+22
| | | | | | | | | | | | | | | | | lighter-weight so that the cache can be populated faster. - I Added a ProcessWP to the runtime so I can take it out of the individual descriptors, saving space; - I made the constructors for the descriptors private so that only the runtime can invoke them; and - I removed the constructor that takes a ValueObject since the logic for using a ValueObject is in the runtime. llvm-svn: 165549
* Changes to clean up the runtime and how the ISA caches are managed.Greg Clayton2012-10-094-321/+324
| | | | llvm-svn: 165516
* Ran the sources through the compiler with -Wshadow warningsJason Molenda2012-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Now in the presence of an Objective-C version 2Sean Callanan2012-09-291-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime, we read method signatures for both class and instance methods out of the runtime data. (lldb) fr var str (NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'" (lldb) expr str.length (unsigned long long) $0 = 72 (lldb) expr [NSString stringWithCString:"Hello world!" encoding:1] (id) $1 = 0x0000000105100050 (lldb) po $1 $1 = 0x0000000105100050 Hello world! (lldb) fr var array1 (NSArray *) array1 = 0x000000010010a6e0 @"3 objects" (lldb) expr array1.count (unsigned long long) $0 = 3 (lldb) expr [array1 objectAtIndex:2] (id) $1 = 0x00000001000025d0 (lldb) po $1 $1 = 0x00000001000025d0 array1 object3 Notice that both regular and property-style notation work. I still need to add explicit support for properties with non-default setters/getters. This information is only queried if an Objective-C object does not have debug information for a complete type available. Otherwise we query debug information as usual. llvm-svn: 164878
* Fixed a bug where if something went wrong whileSean Callanan2012-09-281-0/+4
| | | | | | | | constructing the ObjCInterfaceDecl for an ISA, we'd continue and try to use that Decl anyway, possibly causing a crash. llvm-svn: 164844
* Improved the runtime reading to also get dataSean Callanan2012-09-272-36/+63
| | | | | | | out of the metaclass, so as to enumerate class methods for an object. llvm-svn: 164808
* Fixed some bugs in the runtime reader code. AlsoSean Callanan2012-09-272-7/+320
| | | | | | | added a parser for method signatures in the Objective-C @encode format. llvm-svn: 164792
* Make lldb more C++11 friendly.Filipe Cabecinhas2012-09-261-1/+1
| | | | llvm-svn: 164702
* Fixed an oddity in the Objective-C class descriptorsSean Callanan2012-09-211-15/+15
| | | | | | | | | where the descriptor took a pointer to an object and expected the Initialize function to dereference that pointer and extract the isa value. This caused one of our tests to fail. llvm-svn: 164353
* More work for reading the Objective-C runtime.Sean Callanan2012-09-203-67/+344
| | | | | | | | | We can now read the relevant data structures for the method list, and use a callback mechanism to report their details to the AppleObjCTypeVendor, which constructs appropriate Clang types. llvm-svn: 164310
* Don't get everything when resolving the symbol context of the ObjC Class ↵Greg Clayton2012-09-191-2/+1
| | | | | | symbol, just the module + symbol. llvm-svn: 164257
* Updated AppleObjCV2Runtime to load the classSean Callanan2012-09-192-69/+164
| | | | | | | | | | | | data structures more rapidly. Also added fields for the other data structures in a class. I also fixed a problem where I accidentally used hasExternalLexicalStorage() instead of hasExternalVisibleStorage() to mark an incomplete object. llvm-svn: 164197
* Objective-C runtime class descriptors can nowSean Callanan2012-09-182-8/+113
| | | | | | | | | | | populate Clang ObjCInterfaceDecls with their ivars, methods, and properties. The default implementation does nothing. I have also made sure that AppleObjCRuntimeV2 creates ObjCInterfaceDecls that actually get queried appropriately. llvm-svn: 164164
* Make the Class Descriptors able to fetch the class name for unrealized classesEnrico Granata2012-09-171-1/+28
| | | | llvm-svn: 164050
* Re-applied Enrico's patch that I so rudelySean Callanan2012-09-172-440/+425
| | | | | | stomped on. llvm-svn: 164049
* Stop validating the vtable_ptr since it's not actually guaranteed to be correctEnrico Granata2012-09-171-11/+0
| | | | llvm-svn: 164048
* More runtime work. We now successfully traverseSean Callanan2012-09-152-0/+530
| | | | | | | | | | | | the dynamic and static runtime class tables to construct our isa table. This is putting the runtime in contact with unrealized classes, which we need to deal with in order to get accurate information. That's the next piece of work. <rdar://problem/10986023> llvm-svn: 163957
* <rdar://problem/11086338> Implementing support for synthetic children ↵Enrico Granata2012-09-132-4/+63
| | | | | | generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
* This patch is part of ongoing work to extract typeSean Callanan2012-09-115-105/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | information from the Objective-C runtime. This patch takes the old AppleObjCSymbolVendor and replaces it with an AppleObjCTypeVendor, which is much more lightweight. Specifically, the SymbolVendor needs to pretend that there is a backing symbol file for the Types it vends, whereas a TypeVendor only vends bare ClangASTTypes. These ClangASTTypes only need to exist in an ASTContext. The ClangASTSource now falls back to the runtime's TypeVendor (if one exists) if the debug information doesn't find a complete type for a particular Objective-C interface. The runtime's TypeVendor maintains an ASTContext full of types it knows about, and re-uses the ISA-based type query information used by the ValueObjects. Currently, the runtime's TypeVendor doesn't provide useful answers because we haven't yet implemented a way to iterate across all ISAs contained in the target process's runtime. That's the next step. llvm-svn: 163651
* Patch from Daniel Malea to fix the build on Linux. ThanksEnrico Granata2012-09-062-5/+5
| | | | llvm-svn: 163332
* <rdar://problem/11485744> Implement important data formatters in C++. Have ↵Enrico Granata2012-09-045-155/+689
| | | | | | the Objective-C language runtime plugin expose class descriptors objects akin to the objc_runtime.py Pythonic implementation. Rewrite the data formatters for some core Cocoa classes in C++ instead of Python. llvm-svn: 163155
* <rdar://problem/11757916>Greg Clayton2012-08-293-0/+4
| | | | | | | | | | | | 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
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-221-2/+1
| | | | | | | | | | | | | 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
* <rdar://problem/11672978> Fixing an issue where an ObjC object might come ↵Enrico Granata2012-07-161-1/+1
| | | | | | out without a description because the expression used to obtain it would timeout before running to completion llvm-svn: 160326
* We were accessing the ModuleList in the target without locking it for tasks likeJim Ingham2012-05-303-10/+14
| | | | | | | | | | | setting breakpoints. That's dangerous, since while we are setting a breakpoint, the target might hit the dyld load notification, and start removing modules from the list. This change adds a GetMutex accessor to the ModuleList class, and uses it whenever we are accessing the target's ModuleList (as returned by GetImages().) <rdar://problem/11552372> llvm-svn: 157668
* Return a constant of the appropriate type.Filipe Cabecinhas2012-05-221-2/+2
| | | | llvm-svn: 157241
* <rdar://problem/11355592> Fixing a bug where we would incorrectly try and ↵Enrico Granata2012-05-211-5/+4
| | | | | | determine a dynamic type for a variable of a pointer type that is not a valid generic type for dynamic pointers. llvm-svn: 157190
* Make the debug output that comes as printf's from code called in the target ↵Jim Ingham2012-05-182-2/+2
| | | | | | for getting ObjC class names and ObjC method implementations only come out when doing verbose logging. llvm-svn: 157029
* I have updated Clang to include support for Objective-CSean Callanan2012-05-171-1/+3
| | | | | | | | | | boxed expressions returning numbers and strings. I also added boxed expressions to our testcases, and enabled boxed expressions when libarclite is linked into the inferior. llvm-svn: 157026
* Reduce the timeout value for the "get class name" and "po" functions to .1 ↵Jim Ingham2012-05-172-2/+2
| | | | | | second. 1 second (what they were before) is way too long. llvm-svn: 157009
* Don't try to use "OkayToDiscard" to mean BOTH this plan is a user plan or ↵Jim Ingham2012-05-111-6/+3
| | | | | | | | not AND unwind on error. rdar://problem/11419156 llvm-svn: 156627
* If the ObjC Step Through Trampoline plan causes a target crash, properly ↵Jim Ingham2012-05-101-52/+70
| | | | | | | | | | | | | | propagate the error back to the controlling plans so that they don't lose control. Also change "ThreadPlanStepThrough" to take the return StackID for its backstop breakpoint as an argument to the constructor rather than having it try to figure it out itself, since it might get it wrong whereas the caller always knows where it is coming from. rdar://problem/11402287 llvm-svn: 156529
* Save more memory by not parsing the symbol table for stand alone DWARF ↵Greg Clayton2012-04-261-1/+6
| | | | | | files. We currently have SymbolFile plug-ins which all get the chance to say what they can parse in a symbol file. Prior to this fix we would ask the SymbolFileDWARF plug-in what abilities it had, and it would answer with "everything", and then we would check the SymbolFileSymtab plug-in what abilities it had, in case it had more abilities. The checking that SymbolFileSymtab does is a bit expensive as it pulls in the entire symbol table just to see if it can offer a few scraps of debug information. This causes all stand along DWARF files to pull in their symbol tables even though those symbols will never be used. This fix will check all SymbolFile plug-ins for their abilities and if any plug-in responds with "everything", then we stop the search. llvm-svn: 155638
* We sometimes need to be able to call functions (via Process::RunThreadPlan) ↵Jim Ingham2012-04-074-114/+169
| | | | | | | | | | | | from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
* In a prior commit, I changed the parameters around on a ↵Greg Clayton2012-04-061-1/+1
| | | | | | ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit. llvm-svn: 154182
* <rdar://problem/11113279>Greg Clayton2012-03-261-2/+3
| | | | | | | | | | Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
* Meta classes can't have dynamic types...Jim Ingham2012-03-101-1/+17
| | | | | | <rdar://problem/11021925> llvm-svn: 152473
* Handle the case where we get called to determine the ObjC runtime version ↵Jim Ingham2012-03-091-2/+11
| | | | | | | | | BEFORE the loader code has winnowed all the unloaded libraries from the process module list. <rdar://problem/11015223> llvm-svn: 152427
* First stage of implementing step by "run to next branch". Doesn't work yet, ↵Jim Ingham2012-03-091-23/+2
| | | | | | | | is turned off. <rdar://problem/10975912> llvm-svn: 152376
* Updated the revision of LLVM/Clang used by LLDB.Sean Callanan2012-03-082-0/+21
| | | | | | | | | | | | | | | This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
* Look up ivar offset symbols correctly. We nowSean Callanan2012-03-071-1/+1
| | | | | | | | treat Objective-C ivar symbols as their own kind of symbol rather than lumping them in with generic "runtime" symbols. llvm-svn: 152251
* <rdar://problem/10997402>Greg Clayton2012-03-073-12/+12
| | | | | | | | | | | This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
* Add a command and an SB API to create exception breakpoints. Make the break ↵Jim Ingham2012-03-062-2/+5
| | | | | | output prettier for Exception breakpoints. llvm-svn: 152081
* Make it possible to set Exception breakpoints when the target doesn't yetJim Ingham2012-03-055-34/+30
| | | | | | have a process, then fetch the right runtime resolver when the process is made. llvm-svn: 152015
* First step to making an LanguageRuntime Exception breakpoint API.Jim Ingham2012-03-036-43/+55
| | | | | | <rdar://problem/10196277> llvm-svn: 151965
* <rdar://problem/10103468>Greg Clayton2012-02-242-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-212-4/+5
| | | | | | | | | | | | | | | | | objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
* The second part in thread hardening the internals of LLDB where we makeGreg Clayton2012-02-181-7/+8
| | | | | | | | | | | | | | | | the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
* This checking is part one of trying to add some threading safety to ourGreg Clayton2012-02-172-19/+26
| | | | | | | | | | | | | | | | | | | | | | | | | internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
OpenPOWER on IntegriCloud