History log of /external/lldb/source/Target/CPPLanguageRuntime.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
83d90c5e68f4a977150c6791a49ade7a23c92177 18-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/11398407>

Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.

This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182179 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
296b06d325413723f5aac5988eed977b278a7807 03-Apr-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13506727>

Symbol table function names should support lookups like symbols with debug info.

To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178608 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
dc0a38c5a727cae5362b218a3180d0f4265a619d 27-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11113279>

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.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153482 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
bad9753828b6e0e415e38094bb9627e41d57874c 03-Feb-2012 Enrico Granata <granata.enrico@gmail.com> Adding support for an "equivalents map". This can be useful when compilers emit multiple, different names for the same actual type. In such scenarios, one of the type names can actually be found during a type lookup, while the others are just aliases. This can cause issues when trying to work with these aliased names and being unable to resolve them to an actual type (e.g. getting an SBType for the aliased name).
Currently, no code is using this feature, since we can hopefully rely on the new template support in SBType to get the same stuff done, but the support is there just in case it turns out to be useful for some future need.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149661 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
8b7b2276132c7353cabd22000287b42badc26613 08-Oct-2011 Jim Ingham <jingham@apple.com> Move the responsibility for translating the various eFunctionNameType lookups to the
SymbolFIle (it was done mostly in the BreakpointResolverName resolver before.) Then
tailor our searches to the way the indexed maps are laid out. This removes a bunch
of test case failures using indexed dSYM's.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141428 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
0de37195f17fefb536157b3296a18999116b8125 01-Apr-2011 Jim Ingham <jingham@apple.com> Remove unneeded ExecutionContextScope variables.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128685 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
324067bc91877dbbd6ec3a8663914fa3dbb7e3c9 30-Sep-2010 Jim Ingham <jingham@apple.com> Add "-o" option to "expression" which prints the object description if available.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115115 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
b66cd074ec097b5b0a6f2ce292f5072aa1217ca6 28-Sep-2010 Jim Ingham <jingham@apple.com> Replace the vestigial Value::GetOpaqueCLangQualType with the more correct Value::GetValueOpaqueClangQualType.

But mostly, move the ObjC Trampoline handling code from the MacOSX dyld plugin to the AppleObjCRuntime classes.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114935 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp
642036f22366d47ea8e6f8498bedb92b88f7f79f 23-Sep-2010 Jim Ingham <jingham@apple.com> Committing the skeleton of Language runtime plugin classes.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114620 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/CPPLanguageRuntime.cpp