summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Discriminate between the lldb_private::Type's for ObjC Classes that come ↵Jim Ingham2012-01-121-1/+1
| | | | | | | | | from debug info, and those that are made up from the ObjC runtime symbols. For now the latter contain nothing but the fact that the name describes an ObjC class, and so are not useful for things like dynamic types. llvm-svn: 148059
* Removed function information from the symbol tableSean Callanan2011-12-081-52/+3
| | | | | | | | | | for now to fix testcases. Once we have a valid use for the function information (i.e., once properties returning UnknownAnyTy are allowed, once we read return type information from the runtime, among other uses) I will re-enable this. llvm-svn: 146129
* Because we now call StartTagDeclarationDefinition()Sean Callanan2011-12-051-1/+1
| | | | | | | | | and CompleteTagDeclarationDefinition() on Objective-C interfaces populated by SymbolFileSymtab::FindTypes(), we should mark the interface as forward-declared when we create it. llvm-svn: 145825
* Added the ability for clients to grab a set of symbol table indexes and thenGreg Clayton2011-12-031-89/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add them to a fast lookup map. lldb_private::Symtab now export the following public typedefs: namespace lldb_private { class Symtab { typedef std::vector<uint32_t> IndexCollection; typedef UniqueCStringMap<uint32_t> NameToIndexMap; }; } Clients can then find symbols by name and or type and end up with a Symtab::IndexCollection that is filled with indexes. These indexes can then be put into a name to index lookup map and control if the mangled and demangled names get added to the map: bool add_demangled = true; bool add_mangled = true; Symtab::NameToIndexMap name_to_index; symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index). This can be repeated as many times as needed to get a lookup table that you are happy with, and then this can be sorted: name_to_index.Sort(); Now name lookups can be done using a subset of the symbols you extracted from the symbol table. This is currently being used to extract objective C types from object files when there is no debug info in SymbolFileSymtab. Cleaned up how the objective C types were being vended to be more efficient and fixed some errors in the regular expression that was being used. llvm-svn: 145777
* Testcase fixes with the new symbol lookup code forSean Callanan2011-12-031-18/+9
| | | | | | | | | | | | Objective-C, making symbol lookups for various raw Objective-C symbols work correctly. The IR interpreter makes these lookups because Clang has emitted raw symbol references for ivars and classes. Also improved performance in SymbolFiles, caching the result of asking for SymbolFile abilities. llvm-svn: 145758
* Modified the Objective-C type map in SymbolFileSymtabSean Callanan2011-12-021-2/+2
| | | | | | | | | | to use ConstStrings. The const char*s were assumed to be from ConstStrings before, but since storing a full-on ConstString is no more expensive than storing a const char* it makes better sense to enforce uniqueness with the type checker. llvm-svn: 145688
* Added support for extracting method information fromSean Callanan2011-12-021-1/+102
| | | | | | | | Objective-C symbols. The methods aren't used yet if there is a competing definition in the DWARF; I will resolve that next. llvm-svn: 145675
* Added support to the Objective-C language runtimeSean Callanan2011-11-301-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | to find Objective-C class types by looking in the symbol tables for the individual object files. I did this as follows: - I added code to SymbolFileSymtab that vends Clang types for symbols matching the pattern "_OBJC_CLASS_$_NSMyClassName," making them appear as Objective-C classes. This only occurs in modules that do not have debug information, since otherwise SymbolFileDWARF would be in charge of looking up types. - I made a new SymbolVendor subclass for the Apple Objective-C runtime that is in charge of making global lookups of Objective-C types. It currently just sends out type lookup requests to the appropriate SymbolFiles, but in the future we will probably extend it to query the runtime more completely. I also modified a testcase whose behavior is changed by the fact that we now actually return an Objective-C type for __NSCFString. llvm-svn: 145526
* Completed the glue that passes a ClangNamespaceDecl *Sean Callanan2011-10-131-4/+4
| | | | | | | | down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
* Add a new breakpoint type "break by source regular expression".Jim Ingham2011-09-211-9/+9
| | | | | | | | | Fix the RegularExpression class so it has a real copy constructor. Fix the breakpoint setting with multiple shared libraries so it makes one breakpoint not one per shared library. Add SBFileSpecList, to be used to expose the above to the SB interface (not done yet.) llvm-svn: 140225
* Make sure we have a valid object file before we try getting the symbol tableGreg Clayton2011-06-191-30/+32
| | | | | | so we avoid crashing. llvm-svn: 133376
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-081-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
* Changed the SymbolFile::FindFunction() function calls to only return Greg Clayton2011-01-271-20/+10
| | | | | | | | | | | | | | | | | | lldb_private::Function objects. Previously the SymbolFileSymtab subclass would return lldb_private::Symbol objects when it was asked to find functions. The Module::FindFunctions (...) now take a boolean "bool include_symbols" so that the module can track down functions and symbols, yet functions are found by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are gotten through the ObjectFile plug-ins. Fixed and issue where the DWARF parser might run into incomplete class member function defintions which would make clang mad when we tried to make certain member functions with invalid number of parameters (such as an operator= operator that had no parameters). Now we just avoid and don't complete these incomplete functions. llvm-svn: 124359
* Modified the lldb_private::Type clang type resolving code to handle threeGreg Clayton2010-11-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | cases when getting the clang type: - need only a forward declaration - need a clang type that can be used for layout (members and args/return types) - need a full clang type This allows us to partially parse the clang types and be as lazy as possible. The first case is when we just need to declare a type and we will complete it later. The forward declaration happens only for class/union/structs and enums. The layout type allows us to resolve the full clang type _except_ if we have any modifiers on a pointer or reference (both R and L value). In this case when we are adding members or function args or return types, we only need to know how the type will be laid out and we can defer completing the pointee type until we later need it. The last type means we need a full definition for the clang type. Did some renaming of some enumerations to get rid of the old "DC" prefix (which stands for DebugCore which is no longer around). Modified the clang namespace support to be almost ready to be fed to the expression parser. I made a new ClangNamespaceDecl class that can carry around the AST and the namespace decl so we can copy it into the expression AST. I modified the symbol vendor and symbol file plug-ins to use this new class. llvm-svn: 118976
* Added initial support to the lldb_private::SymbolFile for findingGreg Clayton2010-11-101-0/+5
| | | | | | | | | | | | | | | namespaces by name given an optional symbol context. I might end up dressing up the "clang::NamespaceDecl" into a lldb_private::Namespace class if we need to do more than is currenlty required of namespaces. Currently we only need to be able to lookup a namespace by name when parsing expressions, so I kept it simple for now. The idea here is even though we are passing around a "clang::NamespaceDecl *", that we always have it be an opaque pointer (it is forward declared inside of "lldb/Core/ClangForward.h") and we only use clang::NamespaceDecl implementations inside of ClangASTContext, or ClangASTType when we need to extract information from the namespace decl object. llvm-svn: 118737
* Fixed the forward declaration issue that was present in the DWARF parser afterGreg Clayton2010-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | adding methods to C++ and objective C classes. In order to make methods, we need the function prototype which means we need the arguments. Parsing these could cause a circular reference that caused an assertion. Added a new typedef for the clang opaque types which are just void pointers: lldb::clang_type_t. This appears in lldb-types.h. This was fixed by enabling struct, union, class, and enum types to only get a forward declaration when we make the clang opaque qual type for these types. When they need to actually be resolved, lldb_private::Type will call a new function in the SymbolFile protocol to resolve a clang type when it is not fully defined (clang::TagDecl::getDefinition() returns NULL). This allows us to be a lot more lazy when parsing clang types and keeps down the amount of data that gets parsed into the ASTContext for each module. Getting the clang type from a "lldb_private::Type" object now takes a boolean that indicates if a forward declaration is ok: clang_type_t lldb_private::Type::GetClangType (bool forward_decl_is_ok); So function prototypes that define parameters that are "const T&" can now just parse the forward declaration for type 'T' and we avoid circular references in the type system. llvm-svn: 115012
* Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic.Greg Clayton2010-09-111-4/+3
| | | | | | | | | | | | | | | | | | | They will now be represented as: eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false This simplifies the logic when dealing with symbols and allows for symbols to be coalesced into a single symbol most of the time. Enabled the minimal symbol table for mach-o again after working out all the kinks. We now get nice concise symbol tables and debugging with DWARF in the .o files with a debug map in the binary works well again. There were issues where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and symbol indexes interchangeably. Now that all those issues are resolved debugging is working nicely. llvm-svn: 113678
* Added support for objective C built-in types: id, Class, and SEL. This Greg Clayton2010-08-031-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | involved watching for the objective C built-in types in DWARF and making sure when we convert the DWARF types into clang types that we use the appropriate ASTContext types. Added a way to find and dump types in lldb (something equivalent to gdb's "ptype" command): image lookup --type <TYPENAME> This only works for looking up types by name and won't work with variables. It also currently dumps out verbose internal information. I will modify it to dump more appropriate user level info in my next submission. Hookup up the "FindTypes()" functions in the SymbolFile and SymbolVendor so we can lookup types by name in one or more images. Fixed "image lookup --address <ADDRESS>" to be able to correctly show all symbol context information, but it will only show this extra information when the new "--verbose" flag is used. Updated to latest LLVM to get a few needed fixes. llvm-svn: 110089
* Created lldb::LanguageType by moving an enumeration from the Greg Clayton2010-07-281-2/+2
| | | | | | | | | | | | lldb_private::Language class into the enumerations header so it can be freely used by other interfaces. Added correct objective C class support to the DWARF symbol parser. Prior to this fix we were parsing objective C classes as C++ classes and now that the expression parser is ready to call functions we need to make sure the objective C classes have correct AST types. llvm-svn: 109574
* Added function name types to allow us to set breakpoints by name moreGreg Clayton2010-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+401
llvm-svn: 105619
OpenPOWER on IntegriCloud