maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp

1192 lines
47 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- SymbolFileDWARFDebugMap.cpp ----------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "SymbolFileDWARFDebugMap.h"
#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleList.h"
#include "lldb/Core/PluginManager.h"
#include "lldb/Core/RegularExpression.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Core/Timer.h"
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
#include "lldb/Symbol/ClangExternalASTSourceCallbacks.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolVendor.h"
#include "lldb/Symbol/VariableList.h"
#include "SymbolFileDWARF.h"
using namespace lldb;
using namespace lldb_private;
void
SymbolFileDWARFDebugMap::Initialize()
{
PluginManager::RegisterPlugin (GetPluginNameStatic(),
GetPluginDescriptionStatic(),
CreateInstance);
}
void
SymbolFileDWARFDebugMap::Terminate()
{
PluginManager::UnregisterPlugin (CreateInstance);
}
const char *
SymbolFileDWARFDebugMap::GetPluginNameStatic()
{
Huge memory and performance improvements in the DWARF parser. Address ranges are now split up into two different tables: - one in DWARFDebugInfo that is compile unit specific - one in each DWARFCompileUnit that has exact function DIE offsets This helps keep the size of the aranges down since the main table will get uniqued and sorted and have consecutive ranges merged. We then only parse the compile unit one on demand once we have determined that a compile unit contains the address in question. We also now use the .debug_aranges section if there is one instead of always indexing the DWARF manually. NameToDIE now uses a UniqueCStringMap<dw_offset> map instead of a std::map. std::map is very bulky as each node has 3 pointers and the key and value types. This gets our NameToDIE entry down to 12 bytes each instead of 48 which saves us a lot of memory when we have very large DWARF. DWARFDebugAranges now has a smaller footprint for each range it contains to save on memory. llvm-svn: 139557
2011-09-13 07:21:58 +08:00
return "dwarf-debugmap";
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const char *
SymbolFileDWARFDebugMap::GetPluginDescriptionStatic()
{
return "DWARF and DWARF3 debug symbol file reader (debug map).";
}
SymbolFile*
SymbolFileDWARFDebugMap::CreateInstance (ObjectFile* obj_file)
{
return new SymbolFileDWARFDebugMap (obj_file);
}
SymbolFileDWARFDebugMap::SymbolFileDWARFDebugMap (ObjectFile* ofile) :
SymbolFile(ofile),
m_flags(),
m_compile_unit_infos(),
m_func_indexes(),
<rdar://problem/10681814> Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files. Also fix the parsing of objective C built-in types (Class, id and SEL) so they don't parse more information that is not needed due to the way they are represented in DWARF. llvm-svn: 148016
2012-01-12 12:33:28 +08:00
m_glob_indexes(),
m_supports_DW_AT_APPLE_objc_complete_type (eLazyBoolCalculate)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
SymbolFileDWARFDebugMap::~SymbolFileDWARFDebugMap()
{
}
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
void
SymbolFileDWARFDebugMap::InitializeObject()
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
{
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
// Install our external AST source callbacks so we can complete Clang types.
llvm::OwningPtr<clang::ExternalASTSource> ast_source_ap (
new ClangExternalASTSourceCallbacks (SymbolFileDWARFDebugMap::CompleteTagDecl,
SymbolFileDWARFDebugMap::CompleteObjCInterfaceDecl,
This commit adds broad architectural support for hierarchical inspection of namespaces in the expression parser. ClangExpressionDeclMap hitherto reported that namespaces had been completely imported, even though the namespaces are returned empty. To deal with this situation, ClangASTSource was recently extended with an API to complete incomplete type definitions, and, for greater efficiency, to complete these definitions partially, returning only those objects that have a given name. This commit supports these APIs on LLDB's side, and uses it to provide information on types resident in namespaces. Namespaces are now imported as they were -- that is to say, empty -- but with minimal import mode on. This means that Clang will come back and request their contents by name as needed. We now respond with information on the contained types; this will be followed soon by information on functions and variables. llvm-svn: 133852
2011-06-25 08:44:06 +08:00
NULL,
Adding the DWARF parser side for assited layout where the AST context will ask ExternalASTSource objects to help laying out a type. This is needed because the DWARF typically doesn't contain alignement or packing attribute values, and we need to be able to match up types that the compiler uses in expressions. llvm-svn: 149160
2012-01-28 08:48:57 +08:00
SymbolFileDWARFDebugMap::LayoutRecordType,
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
this));
GetClangASTContext().SetExternalSource (ast_source_ap);
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
}
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
SymbolFileDWARFDebugMap::InitOSO ()
{
if (m_flags.test(kHaveInitializedOSOs))
return;
m_flags.set(kHaveInitializedOSOs);
// In order to get the abilities of this plug-in, we look at the list of
// N_OSO entries (object files) from the symbol table and make sure that
// these files exist and also contain valid DWARF. If we get any of that
// then we return the abilities of the first N_OSO's DWARF.
Symtab* symtab = m_obj_file->GetSymtab();
if (symtab)
{
std::vector<uint32_t> oso_indexes;
Made the DWARF + debug map symbol file parser be much more efficient when it isn't going to actually be used as the symbol file plug-in by looking only for suitable N_OSO symbols and avoiding sorting function (N_FUN) and global/static (N_GSYM/N_STSYM) symbols when there are no suitable N_OSO objects. llvm-svn: 123889
2011-01-20 14:08:59 +08:00
// StreamFile s(stdout);
// symtab->Dump(&s, NULL, eSortOrderNone);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Made the DWARF + debug map symbol file parser be much more efficient when it isn't going to actually be used as the symbol file plug-in by looking only for suitable N_OSO symbols and avoiding sorting function (N_FUN) and global/static (N_GSYM/N_STSYM) symbols when there are no suitable N_OSO objects. llvm-svn: 123889
2011-01-20 14:08:59 +08:00
// When a mach-o symbol is encoded, the n_type field is encoded in bits
// 23:16, and the n_desc field is encoded in bits 15:0.
//
// To find all N_OSO entries that are part of the DWARF + debug map
// we find only object file symbols with the flags value as follows:
// bits 23:16 == 0x66 (N_OSO)
// bits 15: 0 == 0x0001 (specifies this is a debug map object file)
const uint32_t k_oso_symbol_flags_value = 0x660001u;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Made the DWARF + debug map symbol file parser be much more efficient when it isn't going to actually be used as the symbol file plug-in by looking only for suitable N_OSO symbols and avoiding sorting function (N_FUN) and global/static (N_GSYM/N_STSYM) symbols when there are no suitable N_OSO objects. llvm-svn: 123889
2011-01-20 14:08:59 +08:00
const uint32_t oso_index_count = symtab->AppendSymbolIndexesWithTypeAndFlagsValue(eSymbolTypeObjectFile, k_oso_symbol_flags_value, oso_indexes);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (oso_index_count > 0)
{
Made the DWARF + debug map symbol file parser be much more efficient when it isn't going to actually be used as the symbol file plug-in by looking only for suitable N_OSO symbols and avoiding sorting function (N_FUN) and global/static (N_GSYM/N_STSYM) symbols when there are no suitable N_OSO objects. llvm-svn: 123889
2011-01-20 14:08:59 +08:00
symtab->AppendSymbolIndexesWithType (eSymbolTypeCode, Symtab::eDebugYes, Symtab::eVisibilityAny, m_func_indexes);
symtab->AppendSymbolIndexesWithType (eSymbolTypeData, Symtab::eDebugYes, Symtab::eVisibilityAny, m_glob_indexes);
symtab->SortSymbolIndexesByValue(m_func_indexes, true);
symtab->SortSymbolIndexesByValue(m_glob_indexes, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_compile_unit_infos.resize(oso_index_count);
// s.Printf("%s N_OSO symbols:\n", __PRETTY_FUNCTION__);
// symtab->Dump(&s, oso_indexes);
for (uint32_t i=0; i<oso_index_count; ++i)
{
m_compile_unit_infos[i].so_symbol = symtab->SymbolAtIndex(oso_indexes[i] - 1);
if (m_compile_unit_infos[i].so_symbol->GetSiblingIndex() == 0)
m_compile_unit_infos[i].so_symbol = symtab->SymbolAtIndex(oso_indexes[i] - 2);
m_compile_unit_infos[i].oso_symbol = symtab->SymbolAtIndex(oso_indexes[i]);
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
uint32_t sibling_idx = m_compile_unit_infos[i].so_symbol->GetSiblingIndex();
assert (sibling_idx != 0);
assert (sibling_idx > i + 1);
m_compile_unit_infos[i].last_symbol = symtab->SymbolAtIndex (sibling_idx - 1);
m_compile_unit_infos[i].first_symbol_index = symtab->GetIndexForSymbol(m_compile_unit_infos[i].so_symbol);
m_compile_unit_infos[i].last_symbol_index = symtab->GetIndexForSymbol(m_compile_unit_infos[i].last_symbol);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
Module *
SymbolFileDWARFDebugMap::GetModuleByOSOIndex (uint32_t oso_idx)
{
const uint32_t cu_count = GetNumCompileUnits();
if (oso_idx < cu_count)
return GetModuleByCompUnitInfo (&m_compile_unit_infos[oso_idx]);
return NULL;
}
Module *
SymbolFileDWARFDebugMap::GetModuleByCompUnitInfo (CompileUnitInfo *comp_unit_info)
{
if (comp_unit_info->oso_module_sp.get() == NULL)
{
Symbol *oso_symbol = comp_unit_info->oso_symbol;
if (oso_symbol)
{
Fixed an issue where we were resolving paths when we should have been. So the issue here was that we have lldb_private::FileSpec that by default was always resolving a path when using the: FileSpec::FileSpec (const char *path); and in the: void FileSpec::SetFile(const char *pathname, bool resolve = true); This isn't what we want in many many cases. One example is you have "/tmp" on your file system which is really "/private/tmp". You compile code in that directory and end up with debug info that mentions "/tmp/file.c". Then you type: (lldb) breakpoint set --file file.c --line 5 If your current working directory is "/tmp", then "file.c" would be turned into "/private/tmp/file.c" which won't match anything in the debug info. Also, it should have been just a FileSpec with no directory and a filename of "file.c" which could (and should) potentially match any instances of "file.c" in the debug info. So I removed the constructor that just takes a path: FileSpec::FileSpec (const char *path); // REMOVED You must now use the other constructor that has a "bool resolve" parameter that you must always supply: FileSpec::FileSpec (const char *path, bool resolve); I also removed the default parameter to SetFile(): void FileSpec::SetFile(const char *pathname, bool resolve); And fixed all of the code to use the right settings. llvm-svn: 116944
2010-10-21 04:54:39 +08:00
FileSpec oso_file_spec(oso_symbol->GetMangled().GetName().AsCString(), true);
Don't put modules for .o files into the global shared module list. We used to do this because we needed to find the shared pointer for a .o file when the .o file's module was needed in a SymbolContext since the module in a symbol context was a shared pointer. Now that we are using intrusive pointers we don't have this limitation anymore since any instrusive shared pointer can be made from a pointer to an object all on its own. Also switched over to having the Module and SymbolVendor use shared pointers to their object files as had a leak on MacOSX when the SymbolVendor's object file wasn't the same as the Module's (debug info in a stand along file (dSYM file)). Now everything will correctly clean itself up when the module goes away after an executable gets rebuilt. Now we correctly get rid of .o files that are used with the DWARF with debug map executables on subsequent runs since the only shared pointer to the object files in from the DWARF symbol file debug map parser, and when the module gets replaced, it destroys to old one along with all .o files. Also added a small optimization when using BSD archives where we will remove old BSD containers from the shared list when they are outdated. llvm-svn: 140002
2011-09-19 02:59:15 +08:00
// Always create a new module for .o files. Why? Because we
// use the debug map, to add new sections to each .o file and
// even though a .o file might not have changed, the sections
// that get added to the .o file can change.
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
comp_unit_info->oso_module_sp.reset (new Module (oso_file_spec,
m_obj_file->GetModule()->GetArchitecture(),
NULL,
0));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
return comp_unit_info->oso_module_sp.get();
}
bool
SymbolFileDWARFDebugMap::GetFileSpecForSO (uint32_t oso_idx, FileSpec &file_spec)
{
if (oso_idx < m_compile_unit_infos.size())
{
if (!m_compile_unit_infos[oso_idx].so_file)
{
if (m_compile_unit_infos[oso_idx].so_symbol == NULL)
return false;
std::string so_path (m_compile_unit_infos[oso_idx].so_symbol->GetMangled().GetName().AsCString());
if (m_compile_unit_infos[oso_idx].so_symbol[1].GetType() == eSymbolTypeSourceFile)
so_path += m_compile_unit_infos[oso_idx].so_symbol[1].GetMangled().GetName().AsCString();
Fixed an issue where we were resolving paths when we should have been. So the issue here was that we have lldb_private::FileSpec that by default was always resolving a path when using the: FileSpec::FileSpec (const char *path); and in the: void FileSpec::SetFile(const char *pathname, bool resolve = true); This isn't what we want in many many cases. One example is you have "/tmp" on your file system which is really "/private/tmp". You compile code in that directory and end up with debug info that mentions "/tmp/file.c". Then you type: (lldb) breakpoint set --file file.c --line 5 If your current working directory is "/tmp", then "file.c" would be turned into "/private/tmp/file.c" which won't match anything in the debug info. Also, it should have been just a FileSpec with no directory and a filename of "file.c" which could (and should) potentially match any instances of "file.c" in the debug info. So I removed the constructor that just takes a path: FileSpec::FileSpec (const char *path); // REMOVED You must now use the other constructor that has a "bool resolve" parameter that you must always supply: FileSpec::FileSpec (const char *path, bool resolve); I also removed the default parameter to SetFile(): void FileSpec::SetFile(const char *pathname, bool resolve); And fixed all of the code to use the right settings. llvm-svn: 116944
2010-10-21 04:54:39 +08:00
m_compile_unit_infos[oso_idx].so_file.SetFile(so_path.c_str(), true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
file_spec = m_compile_unit_infos[oso_idx].so_file;
return true;
}
return false;
}
ObjectFile *
SymbolFileDWARFDebugMap::GetObjectFileByOSOIndex (uint32_t oso_idx)
{
Module *oso_module = GetModuleByOSOIndex (oso_idx);
if (oso_module)
return oso_module->GetObjectFile();
return NULL;
}
SymbolFileDWARF *
SymbolFileDWARFDebugMap::GetSymbolFile (const SymbolContext& sc)
{
CompileUnitInfo *comp_unit_info = GetCompUnitInfo (sc);
if (comp_unit_info)
return GetSymbolFileByCompUnitInfo (comp_unit_info);
return NULL;
}
ObjectFile *
SymbolFileDWARFDebugMap::GetObjectFileByCompUnitInfo (CompileUnitInfo *comp_unit_info)
{
Module *oso_module = GetModuleByCompUnitInfo (comp_unit_info);
if (oso_module)
return oso_module->GetObjectFile();
return NULL;
}
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
uint32_t
SymbolFileDWARFDebugMap::GetCompUnitInfoIndex (const CompileUnitInfo *comp_unit_info)
{
if (!m_compile_unit_infos.empty())
{
const CompileUnitInfo *first_comp_unit_info = &m_compile_unit_infos.front();
const CompileUnitInfo *last_comp_unit_info = &m_compile_unit_infos.back();
if (first_comp_unit_info <= comp_unit_info && comp_unit_info <= last_comp_unit_info)
return comp_unit_info - first_comp_unit_info;
}
return UINT32_MAX;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
SymbolFileDWARF *
SymbolFileDWARFDebugMap::GetSymbolFileByOSOIndex (uint32_t oso_idx)
{
if (oso_idx < m_compile_unit_infos.size())
return GetSymbolFileByCompUnitInfo (&m_compile_unit_infos[oso_idx]);
return NULL;
}
SymbolFileDWARF *
SymbolFileDWARFDebugMap::GetSymbolFileByCompUnitInfo (CompileUnitInfo *comp_unit_info)
{
if (comp_unit_info->oso_symbol_vendor == NULL)
{
ObjectFile *oso_objfile = GetObjectFileByCompUnitInfo (comp_unit_info);
if (oso_objfile)
{
comp_unit_info->oso_symbol_vendor = oso_objfile->GetModule()->GetSymbolVendor();
// SymbolFileDWARF *oso_dwarf = new SymbolFileDWARF(oso_objfile);
// comp_unit_info->oso_dwarf_sp.reset (oso_dwarf);
if (comp_unit_info->oso_symbol_vendor)
{
Fixed the Objective C method prototypes to be correct (the selectors weren't being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC class names to selectors for easy parsing of all class selectors when we parse the class type. llvm-svn: 116290
2010-10-12 10:24:53 +08:00
// Set a a pointer to this class to set our OSO DWARF file know
// that the DWARF is being used along with a debug map and that
// it will have the remapped sections that we do below.
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
SymbolFileDWARF *oso_symfile = (SymbolFileDWARF *)comp_unit_info->oso_symbol_vendor->GetSymbolFile();
oso_symfile->SetDebugMapSymfile(this);
// Set the ID of the symbol file DWARF to the index of the OSO
// shifted left by 32 bits to provide a unique prefix for any
// UserID's that get created in the symbol file.
oso_symfile->SetID (((uint64_t)GetCompUnitInfoIndex(comp_unit_info) + 1ull) << 32ull);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
comp_unit_info->debug_map_sections_sp.reset(new SectionList);
Symtab *exe_symtab = m_obj_file->GetSymtab();
Module *oso_module = oso_objfile->GetModule();
Symtab *oso_symtab = oso_objfile->GetSymtab();
//#define DEBUG_OSO_DMAP // Do not check in with this defined...
#if defined(DEBUG_OSO_DMAP)
StreamFile s(stdout);
s << "OSO symtab:\n";
oso_symtab->Dump(&s, NULL);
s << "OSO sections before:\n";
oso_objfile->GetSectionList()->Dump(&s, NULL, true);
#endif
///const uint32_t fun_resolve_flags = SymbolContext::Module | eSymbolContextCompUnit | eSymbolContextFunction;
//SectionList *oso_sections = oso_objfile->Sections();
// Now we need to make sections that map from zero based object
// file addresses to where things eneded up in the main executable.
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
uint32_t oso_start_idx = exe_symtab->GetIndexForSymbol (comp_unit_info->oso_symbol);
assert (oso_start_idx != UINT32_MAX);
oso_start_idx += 1;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const uint32_t oso_end_idx = comp_unit_info->so_symbol->GetSiblingIndex();
uint32_t sect_id = 0x10000;
for (uint32_t idx = oso_start_idx; idx < oso_end_idx; ++idx)
{
Symbol *exe_symbol = exe_symtab->SymbolAtIndex(idx);
if (exe_symbol)
{
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
if (exe_symbol->IsDebug() == false)
continue;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
switch (exe_symbol->GetType())
{
Split all of the core of LLDB.framework/lldb.so into a static archive that can be linked against. LLDB.framework/lldb.so exports a very controlled API. Splitting the API into a static library allows other tools (debugserver for now) to use the power of the LLDB debugger core, yet not export it as its API is not portable or maintainable. The Host layer and many of the other internal only APIs can now be statically linked against. Now LLDB.framework/lldb.so links against "liblldb-core.a" instead of compiling the .o files only for the shared library. This fix is only for compiling with Xcode as the Makefile based build already does this. The Xcode projecdt compiler has been changed to LLVM. Anyone using Xcode 3 will need to manually change the compiler back to GCC 4.2, or update to Xcode 4. llvm-svn: 127963
2011-03-20 12:57:14 +08:00
default:
break;
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
case eSymbolTypeCode:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// For each N_FUN, or function that we run into in the debug map
// we make a new section that we add to the sections found in the
// .o file. This new section has the file address set to what the
// addresses are in the .o file, and the load address is adjusted
// to match where it ended up in the final executable! We do this
// before we parse any dwarf info so that when it goes get parsed
// all section/offset addresses that get registered will resolve
// correctly to the new addresses in the main executable.
// First we find the original symbol in the .o file's symbol table
Fixed an issue when debugging with DWARF in the .o files where if two functions had the same demangled names (constructors where we have the in charge and not in charge version) we could end up mixing the two up when making the function in the DWARF. This was because we need to lookup the symbol by name and we need to use the mangled name if there is one. This ensures we get the correct address and that we resolve the linked addresses correctly for DWARf with debug map. llvm-svn: 121116
2010-12-07 15:37:38 +08:00
Symbol *oso_fun_symbol = oso_symtab->FindFirstSymbolWithNameAndType(exe_symbol->GetMangled().GetName(Mangled::ePreferMangled), eSymbolTypeCode, Symtab::eDebugNo, Symtab::eVisibilityAny);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (oso_fun_symbol)
{
// If we found the symbol, then we
Section* exe_fun_section = const_cast<Section *>(exe_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection());
Section* oso_fun_section = const_cast<Section *>(oso_fun_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection());
if (oso_fun_section)
{
// Now we create a section that we will add as a child of the
// section in which the .o symbol (the N_FUN) exists.
// We use the exe_symbol size because the one in the .o file
// will just be a symbol with no size, and the exe_symbol
// size will reflect any size changes (ppc has been known to
// shrink function sizes when it gets rid of jump islands that
// aren't needed anymore).
SectionSP oso_fun_section_sp (new Section (const_cast<Section *>(oso_fun_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection()),
oso_module, // Module (the .o file)
sect_id++, // Section ID starts at 0x10000 and increments so the section IDs don't overlap with the standard mach IDs
Fixed an issue when debugging with DWARF in the .o files where if two functions had the same demangled names (constructors where we have the in charge and not in charge version) we could end up mixing the two up when making the function in the DWARF. This was because we need to lookup the symbol by name and we need to use the mangled name if there is one. This ensures we get the correct address and that we resolve the linked addresses correctly for DWARf with debug map. llvm-svn: 121116
2010-12-07 15:37:38 +08:00
exe_symbol->GetMangled().GetName(Mangled::ePreferMangled), // Name the section the same as the symbol for which is was generated!
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
eSectionTypeDebug,
oso_fun_symbol->GetAddressRangePtr()->GetBaseAddress().GetOffset(), // File VM address offset in the current section
exe_symbol->GetByteSize(), // File size (we need the size from the executable)
0, 0, 0));
oso_fun_section_sp->SetLinkedLocation (exe_fun_section,
exe_symbol->GetValue().GetFileAddress() - exe_fun_section->GetFileAddress());
oso_fun_section->GetChildren().AddSection(oso_fun_section_sp);
comp_unit_info->debug_map_sections_sp->AddSection(oso_fun_section_sp);
}
}
}
break;
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
case eSymbolTypeData:
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// For each N_GSYM we remap the address for the global by making
// a new section that we add to the sections found in the .o file.
// This new section has the file address set to what the
// addresses are in the .o file, and the load address is adjusted
// to match where it ended up in the final executable! We do this
// before we parse any dwarf info so that when it goes get parsed
// all section/offset addresses that get registered will resolve
// correctly to the new addresses in the main executable. We
// initially set the section size to be 1 byte, but will need to
// fix up these addresses further after all globals have been
// parsed to span the gaps, or we can find the global variable
// sizes from the DWARF info as we are parsing.
// Next we find the non-stab entry that corresponds to the N_GSYM in the .o file
<rdar://problem/10338439> This is the actual fix for the above radar where global variables that weren't initialized were not being shown correctly when leaving the DWARF in the .o files. Global variables that aren't intialized have symbols in the .o files that specify they are undefined and external to the .o file, yet document the size of the variable. This allows the compiler to emit a single copy, but makes it harder for our DWARF in .o files with the executable having a debug map because the symbol for the global in the .o file doesn't exist in a section that we can assign a fixed up linked address to, and also the DWARF contains an invalid address in the "DW_OP_addr" location (always zero). This means that the DWARF is incorrect and actually maps all such global varaibles to the first file address in the .o file which is usually the first function. So we can fix this in either of two ways: make a new fake section in the .o file so that we have a file address in the .o file that we can relink, or fix the the variable as it is created in the .o file DWARF parser and actually give it the file address from the executable. Each variable contains a SymbolContextScope, or a single pointer that helps us to recreate where the variables came from (which module, file, function, etc). This context helps us to resolve any file addresses that might be in the location description of the variable by pointing us to which file the file address comes from, so we can just replace the SymbolContextScope and also fix up the location, which we would have had to do for the other case as well, and update the file address. Now globals display correctly. The above changes made it possible to determine if a variable is a global or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag for each variable (local, global, or static), yet DWARF provides no way for us to classify these variables into these categories. We can now detect when a variable has a simple address expressions as its location and this will help us classify these correctly. While making the above changes I also noticed that we had two symbol types: eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same thing: the symbol is not defined in the current object file. Symbol objects also have a bit that specifies if a symbol is externally visible, so I got rid of the eSymbolTypeExtern symbol type and moved all code locations that used it to use the eSymbolTypeUndefined type. llvm-svn: 144489
2011-11-13 12:15:56 +08:00
Symbol *oso_gsym_symbol = oso_symtab->FindFirstSymbolWithNameAndType (exe_symbol->GetMangled().GetName(),
eSymbolTypeData,
Symtab::eDebugNo,
Symtab::eVisibilityAny);
if (exe_symbol && oso_gsym_symbol && exe_symbol->GetAddressRangePtr() && oso_gsym_symbol->GetAddressRangePtr())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// If we found the symbol, then we
<rdar://problem/10338439> This is the actual fix for the above radar where global variables that weren't initialized were not being shown correctly when leaving the DWARF in the .o files. Global variables that aren't intialized have symbols in the .o files that specify they are undefined and external to the .o file, yet document the size of the variable. This allows the compiler to emit a single copy, but makes it harder for our DWARF in .o files with the executable having a debug map because the symbol for the global in the .o file doesn't exist in a section that we can assign a fixed up linked address to, and also the DWARF contains an invalid address in the "DW_OP_addr" location (always zero). This means that the DWARF is incorrect and actually maps all such global varaibles to the first file address in the .o file which is usually the first function. So we can fix this in either of two ways: make a new fake section in the .o file so that we have a file address in the .o file that we can relink, or fix the the variable as it is created in the .o file DWARF parser and actually give it the file address from the executable. Each variable contains a SymbolContextScope, or a single pointer that helps us to recreate where the variables came from (which module, file, function, etc). This context helps us to resolve any file addresses that might be in the location description of the variable by pointing us to which file the file address comes from, so we can just replace the SymbolContextScope and also fix up the location, which we would have had to do for the other case as well, and update the file address. Now globals display correctly. The above changes made it possible to determine if a variable is a global or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag for each variable (local, global, or static), yet DWARF provides no way for us to classify these variables into these categories. We can now detect when a variable has a simple address expressions as its location and this will help us classify these correctly. While making the above changes I also noticed that we had two symbol types: eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same thing: the symbol is not defined in the current object file. Symbol objects also have a bit that specifies if a symbol is externally visible, so I got rid of the eSymbolTypeExtern symbol type and moved all code locations that used it to use the eSymbolTypeUndefined type. llvm-svn: 144489
2011-11-13 12:15:56 +08:00
Section* exe_gsym_section = const_cast<Section *>(exe_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Section* oso_gsym_section = const_cast<Section *>(oso_gsym_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection());
if (oso_gsym_section)
{
SectionSP oso_gsym_section_sp (new Section (const_cast<Section *>(oso_gsym_symbol->GetAddressRangePtr()->GetBaseAddress().GetSection()),
<rdar://problem/10338439> This is the actual fix for the above radar where global variables that weren't initialized were not being shown correctly when leaving the DWARF in the .o files. Global variables that aren't intialized have symbols in the .o files that specify they are undefined and external to the .o file, yet document the size of the variable. This allows the compiler to emit a single copy, but makes it harder for our DWARF in .o files with the executable having a debug map because the symbol for the global in the .o file doesn't exist in a section that we can assign a fixed up linked address to, and also the DWARF contains an invalid address in the "DW_OP_addr" location (always zero). This means that the DWARF is incorrect and actually maps all such global varaibles to the first file address in the .o file which is usually the first function. So we can fix this in either of two ways: make a new fake section in the .o file so that we have a file address in the .o file that we can relink, or fix the the variable as it is created in the .o file DWARF parser and actually give it the file address from the executable. Each variable contains a SymbolContextScope, or a single pointer that helps us to recreate where the variables came from (which module, file, function, etc). This context helps us to resolve any file addresses that might be in the location description of the variable by pointing us to which file the file address comes from, so we can just replace the SymbolContextScope and also fix up the location, which we would have had to do for the other case as well, and update the file address. Now globals display correctly. The above changes made it possible to determine if a variable is a global or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag for each variable (local, global, or static), yet DWARF provides no way for us to classify these variables into these categories. We can now detect when a variable has a simple address expressions as its location and this will help us classify these correctly. While making the above changes I also noticed that we had two symbol types: eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same thing: the symbol is not defined in the current object file. Symbol objects also have a bit that specifies if a symbol is externally visible, so I got rid of the eSymbolTypeExtern symbol type and moved all code locations that used it to use the eSymbolTypeUndefined type. llvm-svn: 144489
2011-11-13 12:15:56 +08:00
oso_module, // Module (the .o file)
sect_id++, // Section ID starts at 0x10000 and increments so the section IDs don't overlap with the standard mach IDs
exe_symbol->GetMangled().GetName(Mangled::ePreferMangled), // Name the section the same as the symbol for which is was generated!
eSectionTypeDebug,
oso_gsym_symbol->GetAddressRangePtr()->GetBaseAddress().GetOffset(), // File VM address offset in the current section
1, // We don't know the size of the global, just do the main address for now.
0, 0, 0));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
oso_gsym_section_sp->SetLinkedLocation (exe_gsym_section,
<rdar://problem/10338439> This is the actual fix for the above radar where global variables that weren't initialized were not being shown correctly when leaving the DWARF in the .o files. Global variables that aren't intialized have symbols in the .o files that specify they are undefined and external to the .o file, yet document the size of the variable. This allows the compiler to emit a single copy, but makes it harder for our DWARF in .o files with the executable having a debug map because the symbol for the global in the .o file doesn't exist in a section that we can assign a fixed up linked address to, and also the DWARF contains an invalid address in the "DW_OP_addr" location (always zero). This means that the DWARF is incorrect and actually maps all such global varaibles to the first file address in the .o file which is usually the first function. So we can fix this in either of two ways: make a new fake section in the .o file so that we have a file address in the .o file that we can relink, or fix the the variable as it is created in the .o file DWARF parser and actually give it the file address from the executable. Each variable contains a SymbolContextScope, or a single pointer that helps us to recreate where the variables came from (which module, file, function, etc). This context helps us to resolve any file addresses that might be in the location description of the variable by pointing us to which file the file address comes from, so we can just replace the SymbolContextScope and also fix up the location, which we would have had to do for the other case as well, and update the file address. Now globals display correctly. The above changes made it possible to determine if a variable is a global or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag for each variable (local, global, or static), yet DWARF provides no way for us to classify these variables into these categories. We can now detect when a variable has a simple address expressions as its location and this will help us classify these correctly. While making the above changes I also noticed that we had two symbol types: eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same thing: the symbol is not defined in the current object file. Symbol objects also have a bit that specifies if a symbol is externally visible, so I got rid of the eSymbolTypeExtern symbol type and moved all code locations that used it to use the eSymbolTypeUndefined type. llvm-svn: 144489
2011-11-13 12:15:56 +08:00
exe_symbol->GetValue().GetFileAddress() - exe_gsym_section->GetFileAddress());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
oso_gsym_section->GetChildren().AddSection(oso_gsym_section_sp);
comp_unit_info->debug_map_sections_sp->AddSection(oso_gsym_section_sp);
}
}
}
break;
}
}
}
#if defined(DEBUG_OSO_DMAP)
s << "OSO sections after:\n";
oso_objfile->GetSectionList()->Dump(&s, NULL, true);
#endif
}
}
}
if (comp_unit_info->oso_symbol_vendor)
return (SymbolFileDWARF *)comp_unit_info->oso_symbol_vendor->GetSymbolFile();
return NULL;
}
uint32_t
Testcase fixes with the new symbol lookup code for 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
2011-12-03 12:38:43 +08:00
SymbolFileDWARFDebugMap::CalculateAbilities ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// In order to get the abilities of this plug-in, we look at the list of
// N_OSO entries (object files) from the symbol table and make sure that
// these files exist and also contain valid DWARF. If we get any of that
// then we return the abilities of the first N_OSO's DWARF.
const uint32_t oso_index_count = GetNumCompileUnits();
if (oso_index_count > 0)
{
const uint32_t dwarf_abilities = SymbolFile::CompileUnits |
SymbolFile::Functions |
SymbolFile::Blocks |
SymbolFile::GlobalVariables |
SymbolFile::LocalVariables |
SymbolFile::VariableTypes |
SymbolFile::LineTables;
for (uint32_t oso_idx=0; oso_idx<oso_index_count; ++oso_idx)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
if (oso_dwarf)
{
uint32_t oso_abilities = oso_dwarf->GetAbilities();
if ((oso_abilities & dwarf_abilities) == dwarf_abilities)
return oso_abilities;
}
}
}
return 0;
}
uint32_t
SymbolFileDWARFDebugMap::GetNumCompileUnits()
{
InitOSO ();
return m_compile_unit_infos.size();
}
CompUnitSP
SymbolFileDWARFDebugMap::ParseCompileUnitAtIndex(uint32_t cu_idx)
{
CompUnitSP comp_unit_sp;
const uint32_t cu_count = GetNumCompileUnits();
if (cu_idx < cu_count)
{
if (m_compile_unit_infos[cu_idx].oso_compile_unit_sp.get() == NULL)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (cu_idx);
if (oso_dwarf)
{
// There is only one compile unit for N_OSO entry right now, so
// it will always exist at index zero.
m_compile_unit_infos[cu_idx].oso_compile_unit_sp = m_compile_unit_infos[cu_idx].oso_symbol_vendor->GetCompileUnitAtIndex (0);
}
if (m_compile_unit_infos[cu_idx].oso_compile_unit_sp.get() == NULL)
{
// We weren't able to get the DWARF for this N_OSO entry (the
// .o file may be missing or not at the specified path), make
// one up as best we can from the debug map. We set the uid
// of the compile unit to the symbol index with the MSBit set
// so that it doesn't collide with any uid values from the DWARF
Symbol *so_symbol = m_compile_unit_infos[cu_idx].so_symbol;
if (so_symbol)
{
m_compile_unit_infos[cu_idx].oso_compile_unit_sp.reset(new CompileUnit (m_obj_file->GetModule(),
NULL,
so_symbol->GetMangled().GetName().AsCString(),
cu_idx,
Created lldb::LanguageType by moving an enumeration from the 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
2010-07-28 10:04:09 +08:00
eLanguageTypeUnknown));
Fixed the Objective C method prototypes to be correct (the selectors weren't being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC class names to selectors for easy parsing of all class selectors when we parse the class type. llvm-svn: 116290
2010-10-12 10:24:53 +08:00
// Let our symbol vendor know about this compile unit
m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex (m_compile_unit_infos[cu_idx].oso_compile_unit_sp,
cu_idx);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
comp_unit_sp = m_compile_unit_infos[cu_idx].oso_compile_unit_sp;
}
return comp_unit_sp;
}
SymbolFileDWARFDebugMap::CompileUnitInfo *
SymbolFileDWARFDebugMap::GetCompUnitInfo (const SymbolContext& sc)
{
const uint32_t cu_count = GetNumCompileUnits();
for (uint32_t i=0; i<cu_count; ++i)
{
if (sc.comp_unit == m_compile_unit_infos[i].oso_compile_unit_sp.get())
return &m_compile_unit_infos[i];
}
return NULL;
}
size_t
SymbolFileDWARFDebugMap::ParseCompileUnitFunctions (const SymbolContext& sc)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseCompileUnitFunctions (sc);
return 0;
}
bool
SymbolFileDWARFDebugMap::ParseCompileUnitLineTable (const SymbolContext& sc)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseCompileUnitLineTable (sc);
return false;
}
bool
SymbolFileDWARFDebugMap::ParseCompileUnitSupportFiles (const SymbolContext& sc, FileSpecList &support_files)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseCompileUnitSupportFiles (sc, support_files);
return false;
}
size_t
SymbolFileDWARFDebugMap::ParseFunctionBlocks (const SymbolContext& sc)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseFunctionBlocks (sc);
return 0;
}
size_t
SymbolFileDWARFDebugMap::ParseTypes (const SymbolContext& sc)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseTypes (sc);
return 0;
}
size_t
SymbolFileDWARFDebugMap::ParseVariablesForContext (const SymbolContext& sc)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
return oso_dwarf->ParseTypes (sc);
return 0;
}
Type*
SymbolFileDWARFDebugMap::ResolveTypeUID(lldb::user_id_t type_uid)
{
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
const uint64_t oso_idx = GetOSOIndexFromUserID (type_uid);
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
if (oso_dwarf)
oso_dwarf->ResolveTypeUID (type_uid);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return NULL;
}
Fixed the forward declaration issue that was present in the DWARF parser after 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
2010-09-29 09:12:09 +08:00
lldb::clang_type_t
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
SymbolFileDWARFDebugMap::ResolveClangOpaqueTypeDefinition (lldb::clang_type_t clang_type)
Fixed the forward declaration issue that was present in the DWARF parser after 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
2010-09-29 09:12:09 +08:00
{
// We have a struct/union/class/enum that needs to be fully resolved.
return NULL;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t
SymbolFileDWARFDebugMap::ResolveSymbolContext (const Address& exe_so_addr, uint32_t resolve_scope, SymbolContext& sc)
{
uint32_t resolved_flags = 0;
Symtab* symtab = m_obj_file->GetSymtab();
if (symtab)
{
const addr_t exe_file_addr = exe_so_addr.GetFileAddress();
sc.symbol = symtab->FindSymbolContainingFileAddress (exe_file_addr, &m_func_indexes[0], m_func_indexes.size());
if (sc.symbol != NULL)
{
resolved_flags |= eSymbolContextSymbol;
uint32_t oso_idx = 0;
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
CompileUnitInfo* comp_unit_info = GetCompileUnitInfoForSymbolWithID (sc.symbol->GetID(), &oso_idx);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (comp_unit_info)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
ObjectFile *oso_objfile = GetObjectFileByOSOIndex (oso_idx);
if (oso_dwarf && oso_objfile)
{
SectionList *oso_section_list = oso_objfile->GetSectionList();
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
SectionSP oso_symbol_section_sp (oso_section_list->FindSectionContainingLinkedFileAddress (exe_file_addr, UINT32_MAX));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
if (oso_symbol_section_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
const addr_t linked_file_addr = oso_symbol_section_sp->GetLinkedFileAddress();
Address oso_so_addr (oso_symbol_section_sp.get(), exe_file_addr - linked_file_addr);
if (oso_so_addr.IsSectionOffset())
resolved_flags |= oso_dwarf->ResolveSymbolContext (oso_so_addr, resolve_scope, sc);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
}
return resolved_flags;
}
uint32_t
SymbolFileDWARFDebugMap::ResolveSymbolContext (const FileSpec& file_spec, uint32_t line, bool check_inlines, uint32_t resolve_scope, SymbolContextList& sc_list)
{
uint32_t initial = sc_list.GetSize();
const uint32_t cu_count = GetNumCompileUnits();
FileSpec so_file_spec;
for (uint32_t i=0; i<cu_count; ++i)
{
if (GetFileSpecForSO (i, so_file_spec))
{
// By passing false to the comparison we will be able to match
// and files given a filename only. If both file_spec and
// so_file_spec have directories, we will still do a full match.
if (FileSpec::Compare (file_spec, so_file_spec, false) == 0)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (i);
Don't dereference the oso_dwarf without checking for NULL. llvm-svn: 148005
2012-01-12 09:45:53 +08:00
if (oso_dwarf)
oso_dwarf->ResolveSymbolContext(file_spec, line, check_inlines, resolve_scope, sc_list);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
return sc_list.GetSize() - initial;
}
uint32_t
SymbolFileDWARFDebugMap::PrivateFindGlobalVariables
(
const ConstString &name,
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
const ClangNamespaceDecl *namespace_decl,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const std::vector<uint32_t> &indexes, // Indexes into the symbol table that match "name"
uint32_t max_matches,
VariableList& variables
)
{
const uint32_t original_size = variables.GetSize();
const size_t match_count = indexes.size();
for (size_t i=0; i<match_count; ++i)
{
uint32_t oso_idx;
CompileUnitInfo* comp_unit_info = GetCompileUnitInfoForSymbolWithIndex (indexes[i], &oso_idx);
if (comp_unit_info)
{
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
if (oso_dwarf)
{
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
if (oso_dwarf->FindGlobalVariables(name, namespace_decl, true, max_matches, variables))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (variables.GetSize() > max_matches)
break;
}
}
}
return variables.GetSize() - original_size;
}
uint32_t
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
SymbolFileDWARFDebugMap::FindGlobalVariables (const ConstString &name, const ClangNamespaceDecl *namespace_decl, bool append, uint32_t max_matches, VariableList& variables)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// If we aren't appending the results to this list, then clear the list
if (!append)
variables.Clear();
// Remember how many variables are in the list before we search in case
// we are appending the results to a variable list.
const uint32_t original_size = variables.GetSize();
Fixed an issue where we might not find global variables by name when we have a debug map with DWARF in the .o files due to the attemted shortcut that was being taken where the global variables were being searched for by looking in the symbol table. The problem with the symbols in the symbol table is we don't break apart the symbol names for symbols when they are mangled into basename and the fully mangled name since this would take a lot of CPU time to chop up the mangled names and try and find the basenames. The DWARF info typically has this broken up for us where the basename of the variable is in a the DW_AT_name attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute. Now we correctly find globals by searching all OSO's for the information so we can take advantage of this split information. llvm-svn: 119012
2010-11-14 06:57:37 +08:00
uint32_t total_matches = 0;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
const uint32_t oso_matches = oso_dwarf->FindGlobalVariables (name,
namespace_decl,
Fixed an issue where we might not find global variables by name when we have a debug map with DWARF in the .o files due to the attemted shortcut that was being taken where the global variables were being searched for by looking in the symbol table. The problem with the symbols in the symbol table is we don't break apart the symbol names for symbols when they are mangled into basename and the fully mangled name since this would take a lot of CPU time to chop up the mangled names and try and find the basenames. The DWARF info typically has this broken up for us where the basename of the variable is in a the DW_AT_name attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute. Now we correctly find globals by searching all OSO's for the information so we can take advantage of this split information. llvm-svn: 119012
2010-11-14 06:57:37 +08:00
true,
max_matches,
variables);
if (oso_matches > 0)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fixed an issue where we might not find global variables by name when we have a debug map with DWARF in the .o files due to the attemted shortcut that was being taken where the global variables were being searched for by looking in the symbol table. The problem with the symbols in the symbol table is we don't break apart the symbol names for symbols when they are mangled into basename and the fully mangled name since this would take a lot of CPU time to chop up the mangled names and try and find the basenames. The DWARF info typically has this broken up for us where the basename of the variable is in a the DW_AT_name attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute. Now we correctly find globals by searching all OSO's for the information so we can take advantage of this split information. llvm-svn: 119012
2010-11-14 06:57:37 +08:00
total_matches += oso_matches;
// Are we getting all matches?
if (max_matches == UINT32_MAX)
continue; // Yep, continue getting everything
// If we have found enough matches, lets get out
if (max_matches >= total_matches)
break;
// Update the max matches for any subsequent calls to find globals
// in any other object files with DWARF
max_matches -= oso_matches;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
// Return the number of variable that were appended to the list
return variables.GetSize() - original_size;
}
uint32_t
SymbolFileDWARFDebugMap::FindGlobalVariables (const RegularExpression& regex, bool append, uint32_t max_matches, VariableList& variables)
{
Fixed an issue where we might not find global variables by name when we have a debug map with DWARF in the .o files due to the attemted shortcut that was being taken where the global variables were being searched for by looking in the symbol table. The problem with the symbols in the symbol table is we don't break apart the symbol names for symbols when they are mangled into basename and the fully mangled name since this would take a lot of CPU time to chop up the mangled names and try and find the basenames. The DWARF info typically has this broken up for us where the basename of the variable is in a the DW_AT_name attribute, and the mangled name is in the DW_AT_MIPS_linkage_name attribute. Now we correctly find globals by searching all OSO's for the information so we can take advantage of this split information. llvm-svn: 119012
2010-11-14 06:57:37 +08:00
// If we aren't appending the results to this list, then clear the list
if (!append)
variables.Clear();
// Remember how many variables are in the list before we search in case
// we are appending the results to a variable list.
const uint32_t original_size = variables.GetSize();
uint32_t total_matches = 0;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
const uint32_t oso_matches = oso_dwarf->FindGlobalVariables (regex,
true,
max_matches,
variables);
if (oso_matches > 0)
{
total_matches += oso_matches;
// Are we getting all matches?
if (max_matches == UINT32_MAX)
continue; // Yep, continue getting everything
// If we have found enough matches, lets get out
if (max_matches >= total_matches)
break;
// Update the max matches for any subsequent calls to find globals
// in any other object files with DWARF
max_matches -= oso_matches;
}
}
// Return the number of variable that were appended to the list
return variables.GetSize() - original_size;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
int
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
SymbolFileDWARFDebugMap::SymbolContainsSymbolWithIndex (uint32_t *symbol_idx_ptr, const CompileUnitInfo *comp_unit_info)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
const uint32_t symbol_idx = *symbol_idx_ptr;
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
if (symbol_idx < comp_unit_info->first_symbol_index)
return -1;
if (symbol_idx <= comp_unit_info->last_symbol_index)
return 0;
return 1;
}
int
SymbolFileDWARFDebugMap::SymbolContainsSymbolWithID (user_id_t *symbol_idx_ptr, const CompileUnitInfo *comp_unit_info)
{
const user_id_t symbol_id = *symbol_idx_ptr;
if (symbol_id < comp_unit_info->so_symbol->GetID())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return -1;
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
if (symbol_id <= comp_unit_info->last_symbol->GetID())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return 0;
return 1;
}
SymbolFileDWARFDebugMap::CompileUnitInfo*
SymbolFileDWARFDebugMap::GetCompileUnitInfoForSymbolWithIndex (uint32_t symbol_idx, uint32_t *oso_idx_ptr)
{
const uint32_t oso_index_count = m_compile_unit_infos.size();
CompileUnitInfo *comp_unit_info = NULL;
if (oso_index_count)
{
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
comp_unit_info = (CompileUnitInfo*)bsearch(&symbol_idx,
&m_compile_unit_infos[0],
m_compile_unit_infos.size(),
sizeof(CompileUnitInfo),
(ComparisonFunction)SymbolContainsSymbolWithIndex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
if (oso_idx_ptr)
{
if (comp_unit_info != NULL)
*oso_idx_ptr = comp_unit_info - &m_compile_unit_infos[0];
else
*oso_idx_ptr = UINT32_MAX;
}
return comp_unit_info;
}
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
SymbolFileDWARFDebugMap::CompileUnitInfo*
SymbolFileDWARFDebugMap::GetCompileUnitInfoForSymbolWithID (user_id_t symbol_id, uint32_t *oso_idx_ptr)
{
const uint32_t oso_index_count = m_compile_unit_infos.size();
CompileUnitInfo *comp_unit_info = NULL;
if (oso_index_count)
{
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
comp_unit_info = (CompileUnitInfo*)::bsearch (&symbol_id,
&m_compile_unit_infos[0],
m_compile_unit_infos.size(),
sizeof(CompileUnitInfo),
(ComparisonFunction)SymbolContainsSymbolWithID);
Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic. 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
2010-09-11 11:13:28 +08:00
}
if (oso_idx_ptr)
{
if (comp_unit_info != NULL)
*oso_idx_ptr = comp_unit_info - &m_compile_unit_infos[0];
else
*oso_idx_ptr = UINT32_MAX;
}
return comp_unit_info;
}
Fixed an issue where we would return matches for DWARF in the .o files when the resulting function from the .o file DWARF didn't make it into the final executable. I recently changed the way FindFunctions() worked in the DWARF with debug map case that caused regressions in our test suite for dead stripped functions. The previous changes allowed us to leverage the powerful searching added to the DWARF parser (search by full name, basename, selector, or method name), without having to chop up the symbol names from the symbol table and do any special parsing of the names to extract the basename, selector or method. Previously we would look through the symbol table for matches first, then try and find the .o file with DWARF for that symbol and only search those .o files. Now we let the DWARF for the .o file search using the new search styles, and filter out any functions that didn't make it. llvm-svn: 111322
2010-08-18 07:16:15 +08:00
static void
RemoveFunctionsWithModuleNotEqualTo (Module *module, SymbolContextList &sc_list, uint32_t start_idx)
{
// We found functions in .o files. Not all functions in the .o files
// will have made it into the final output file. The ones that did
// make it into the final output file will have a section whose module
// matches the module from the ObjectFile for this SymbolFile. When
// the modules don't match, then we have something that was in a
// .o file, but doesn't map to anything in the final executable.
uint32_t i=start_idx;
while (i < sc_list.GetSize())
{
SymbolContext sc;
sc_list.GetContextAtIndex(i, sc);
if (sc.function)
{
const Section *section = sc.function->GetAddressRange().GetBaseAddress().GetSection();
if (section->GetModule() != module)
{
sc_list.RemoveContextAtIndex(i);
continue;
}
}
++i;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
SymbolFileDWARFDebugMap::FindFunctions(const ConstString &name, const ClangNamespaceDecl *namespace_decl, uint32_t name_type_mask, bool append, SymbolContextList& sc_list)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Timer scoped_timer (__PRETTY_FUNCTION__,
"SymbolFileDWARFDebugMap::FindFunctions (name = %s)",
name.GetCString());
uint32_t initial_size = 0;
if (append)
initial_size = sc_list.GetSize();
else
sc_list.Clear();
Fixed FindFunctions so it works with all the new name types for the DWARF in object files case. llvm-svn: 111215
2010-08-17 08:35:34 +08:00
uint32_t oso_idx = 0;
SymbolFileDWARF *oso_dwarf;
while ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx++)) != NULL)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fixed an issue where we would return matches for DWARF in the .o files when the resulting function from the .o file DWARF didn't make it into the final executable. I recently changed the way FindFunctions() worked in the DWARF with debug map case that caused regressions in our test suite for dead stripped functions. The previous changes allowed us to leverage the powerful searching added to the DWARF parser (search by full name, basename, selector, or method name), without having to chop up the symbol names from the symbol table and do any special parsing of the names to extract the basename, selector or method. Previously we would look through the symbol table for matches first, then try and find the .o file with DWARF for that symbol and only search those .o files. Now we let the DWARF for the .o file search using the new search styles, and filter out any functions that didn't make it. llvm-svn: 111322
2010-08-18 07:16:15 +08:00
uint32_t sc_idx = sc_list.GetSize();
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
if (oso_dwarf->FindFunctions(name, namespace_decl, name_type_mask, true, sc_list))
Fixed an issue where we would return matches for DWARF in the .o files when the resulting function from the .o file DWARF didn't make it into the final executable. I recently changed the way FindFunctions() worked in the DWARF with debug map case that caused regressions in our test suite for dead stripped functions. The previous changes allowed us to leverage the powerful searching added to the DWARF parser (search by full name, basename, selector, or method name), without having to chop up the symbol names from the symbol table and do any special parsing of the names to extract the basename, selector or method. Previously we would look through the symbol table for matches first, then try and find the .o file with DWARF for that symbol and only search those .o files. Now we let the DWARF for the .o file search using the new search styles, and filter out any functions that didn't make it. llvm-svn: 111322
2010-08-18 07:16:15 +08:00
{
RemoveFunctionsWithModuleNotEqualTo (m_obj_file->GetModule(), sc_list, sc_idx);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return sc_list.GetSize() - initial_size;
}
uint32_t
SymbolFileDWARFDebugMap::FindFunctions (const RegularExpression& regex, bool append, SymbolContextList& sc_list)
{
Timer scoped_timer (__PRETTY_FUNCTION__,
"SymbolFileDWARFDebugMap::FindFunctions (regex = '%s')",
regex.GetText());
Fixed FindFunctions so it works with all the new name types for the DWARF in object files case. llvm-svn: 111215
2010-08-17 08:35:34 +08:00
uint32_t initial_size = 0;
if (append)
initial_size = sc_list.GetSize();
else
sc_list.Clear();
uint32_t oso_idx = 0;
SymbolFileDWARF *oso_dwarf;
while ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx++)) != NULL)
{
Fixed an issue where we would return matches for DWARF in the .o files when the resulting function from the .o file DWARF didn't make it into the final executable. I recently changed the way FindFunctions() worked in the DWARF with debug map case that caused regressions in our test suite for dead stripped functions. The previous changes allowed us to leverage the powerful searching added to the DWARF parser (search by full name, basename, selector, or method name), without having to chop up the symbol names from the symbol table and do any special parsing of the names to extract the basename, selector or method. Previously we would look through the symbol table for matches first, then try and find the .o file with DWARF for that symbol and only search those .o files. Now we let the DWARF for the .o file search using the new search styles, and filter out any functions that didn't make it. llvm-svn: 111322
2010-08-18 07:16:15 +08:00
uint32_t sc_idx = sc_list.GetSize();
if (oso_dwarf->FindFunctions(regex, true, sc_list))
{
RemoveFunctionsWithModuleNotEqualTo (m_obj_file->GetModule(), sc_list, sc_idx);
}
Fixed FindFunctions so it works with all the new name types for the DWARF in object files case. llvm-svn: 111215
2010-08-17 08:35:34 +08:00
}
return sc_list.GetSize() - initial_size;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Modified the DWARF parser for both the single DWARF file and for the case where the DWARF is in the .o files so they can track down the actual type for a forward declaration. This was working before for just DWARF files, but not for DWARF in .o files where the actual definition was in another .o file. Modified the main thread name in the driver to be more consistent with the other LLDB thread names. llvm-svn: 118383
2010-11-08 05:02:03 +08:00
TypeSP
Added code to make sure we don't recursively try to find an objective C class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
2011-12-03 12:40:03 +08:00
SymbolFileDWARFDebugMap::FindDefinitionTypeForDIE (DWARFCompileUnit* cu,
const DWARFDebugInfoEntry *die,
const ConstString &type_name)
Modified the DWARF parser for both the single DWARF file and for the case where the DWARF is in the .o files so they can track down the actual type for a forward declaration. This was working before for just DWARF files, but not for DWARF in .o files where the actual definition was in another .o file. Modified the main thread name in the driver to be more consistent with the other LLDB thread names. llvm-svn: 118383
2010-11-08 05:02:03 +08:00
{
TypeSP type_sp;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
type_sp = oso_dwarf->FindDefinitionTypeForDIE (cu, die, type_name);
if (type_sp)
break;
}
return type_sp;
}
Added support for objective C built-in types: id, Class, and SEL. This 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
2010-08-03 08:35:52 +08:00
Added code to make sure we don't recursively try to find an objective C class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
2011-12-03 12:40:03 +08:00
<rdar://problem/10681814> Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files. Also fix the parsing of objective C built-in types (Class, id and SEL) so they don't parse more information that is not needed due to the way they are represented in DWARF. llvm-svn: 148016
2012-01-12 12:33:28 +08:00
bool
SymbolFileDWARFDebugMap::Supports_DW_AT_APPLE_objc_complete_type (SymbolFileDWARF *skip_dwarf_oso)
{
if (m_supports_DW_AT_APPLE_objc_complete_type == eLazyBoolCalculate)
{
m_supports_DW_AT_APPLE_objc_complete_type = eLazyBoolNo;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
if (skip_dwarf_oso != oso_dwarf && oso_dwarf->Supports_DW_AT_APPLE_objc_complete_type(NULL))
{
m_supports_DW_AT_APPLE_objc_complete_type = eLazyBoolYes;
break;
}
}
}
return m_supports_DW_AT_APPLE_objc_complete_type == eLazyBoolYes;
}
Added code to make sure we don't recursively try to find an objective C class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
2011-12-03 12:40:03 +08:00
TypeSP
<rdar://problem/10681814> Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files. Also fix the parsing of objective C built-in types (Class, id and SEL) so they don't parse more information that is not needed due to the way they are represented in DWARF. llvm-svn: 148016
2012-01-12 12:33:28 +08:00
SymbolFileDWARFDebugMap::FindCompleteObjCDefinitionTypeForDIE (const DWARFDebugInfoEntry *die,
const ConstString &type_name,
bool must_be_implementation)
Added code to make sure we don't recursively try to find an objective C class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
2011-12-03 12:40:03 +08:00
{
TypeSP type_sp;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
<rdar://problem/10681814> Fix DWARF parsing issue we can run into when using llvm-gcc based dSYM files. Also fix the parsing of objective C built-in types (Class, id and SEL) so they don't parse more information that is not needed due to the way they are represented in DWARF. llvm-svn: 148016
2012-01-12 12:33:28 +08:00
type_sp = oso_dwarf->FindCompleteObjCDefinitionTypeForDIE (die, type_name, must_be_implementation);
Added code to make sure we don't recursively try to find an objective C class. The thing with Objective C classes is the debug info might have a definition that isn't just a forward decl, but it is incomplete. So we need to look and see if we can find the complete definition and avoid recursing a lot due to the fact that our accelerator tables will have many versions of the type, but only one complete one. We might not also have the complete type and we need to deal with this correctly. llvm-svn: 145759
2011-12-03 12:40:03 +08:00
if (type_sp)
break;
}
return type_sp;
}
Added support for objective C built-in types: id, Class, and SEL. This 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
2010-08-03 08:35:52 +08:00
uint32_t
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
SymbolFileDWARFDebugMap::FindTypes
(
const SymbolContext& sc,
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
const ConstString &name,
const ClangNamespaceDecl *namespace_decl,
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
bool append,
uint32_t max_matches,
TypeList& types
)
Added support for objective C built-in types: id, Class, and SEL. This 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
2010-08-03 08:35:52 +08:00
{
if (!append)
types.Clear();
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
const uint32_t initial_types_size = types.GetSize();
SymbolFileDWARF *oso_dwarf;
if (sc.comp_unit)
{
oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
return oso_dwarf->FindTypes (sc, name, namespace_decl, append, max_matches, types);
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
}
else
{
uint32_t oso_idx = 0;
while ((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx++)) != NULL)
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
oso_dwarf->FindTypes (sc, name, namespace_decl, append, max_matches, types);
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
}
return types.GetSize() - initial_types_size;
Added support for objective C built-in types: id, Class, and SEL. This 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
2010-08-03 08:35:52 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
//uint32_t
//SymbolFileDWARFDebugMap::FindTypes (const SymbolContext& sc, const RegularExpression& regex, bool append, uint32_t max_matches, Type::Encoding encoding, lldb::user_id_t udt_uid, TypeList& types)
//{
// SymbolFileDWARF *oso_dwarf = GetSymbolFile (sc);
// if (oso_dwarf)
// return oso_dwarf->FindTypes (sc, regex, append, max_matches, encoding, udt_uid, types);
// return 0;
//}
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
Modified the lldb_private::Type clang type resolving code to handle three 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
2010-11-13 11:52:47 +08:00
ClangNamespaceDecl
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
SymbolFileDWARFDebugMap::FindNamespace (const lldb_private::SymbolContext& sc,
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
const lldb_private::ConstString &name,
const ClangNamespaceDecl *parent_namespace_decl)
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
{
Modified the lldb_private::Type clang type resolving code to handle three 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
2010-11-13 11:52:47 +08:00
ClangNamespaceDecl matching_namespace;
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
SymbolFileDWARF *oso_dwarf;
if (sc.comp_unit)
{
oso_dwarf = GetSymbolFile (sc);
if (oso_dwarf)
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
matching_namespace = oso_dwarf->FindNamespace (sc, name, parent_namespace_decl);
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
}
else
{
for (uint32_t oso_idx = 0;
((oso_dwarf = GetSymbolFileByOSOIndex (oso_idx)) != NULL);
++oso_idx)
{
Completed the glue that passes a ClangNamespaceDecl * down through Module and SymbolVendor into SymbolFile. Added checks to SymbolFileDWARF that restrict symbol searches when a namespace is passed in. llvm-svn: 141847
2011-10-13 09:49:10 +08:00
matching_namespace = oso_dwarf->FindNamespace (sc, name, parent_namespace_decl);
Added initial support to the lldb_private::SymbolFile for finding 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
2010-11-11 07:42:09 +08:00
if (matching_namespace)
break;
}
}
return matching_namespace;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//------------------------------------------------------------------
// PluginInterface protocol
//------------------------------------------------------------------
const char *
SymbolFileDWARFDebugMap::GetPluginName()
{
return "SymbolFileDWARFDebugMap";
}
const char *
SymbolFileDWARFDebugMap::GetShortPluginName()
{
return GetPluginNameStatic();
}
uint32_t
SymbolFileDWARFDebugMap::GetPluginVersion()
{
return 1;
}
Fixed the Objective C method prototypes to be correct (the selectors weren't being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC class names to selectors for easy parsing of all class selectors when we parse the class type. llvm-svn: 116290
2010-10-12 10:24:53 +08:00
void
SymbolFileDWARFDebugMap::SetCompileUnit (SymbolFileDWARF *oso_dwarf, const CompUnitSP &cu_sp)
{
const uint32_t cu_count = GetNumCompileUnits();
for (uint32_t i=0; i<cu_count; ++i)
{
if (m_compile_unit_infos[i].oso_symbol_vendor &&
m_compile_unit_infos[i].oso_symbol_vendor->GetSymbolFile() == oso_dwarf)
{
if (m_compile_unit_infos[i].oso_compile_unit_sp)
{
assert (m_compile_unit_infos[i].oso_compile_unit_sp.get() == cu_sp.get());
}
else
{
m_compile_unit_infos[i].oso_compile_unit_sp = cu_sp;
}
}
}
}
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
void
SymbolFileDWARFDebugMap::CompleteTagDecl (void *baton, clang::TagDecl *decl)
{
SymbolFileDWARFDebugMap *symbol_file_dwarf = (SymbolFileDWARFDebugMap *)baton;
clang_type_t clang_type = symbol_file_dwarf->GetClangASTContext().GetTypeForDecl (decl);
if (clang_type)
{
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = symbol_file_dwarf->GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
if (oso_dwarf->HasForwardDeclForClangType (clang_type))
{
oso_dwarf->ResolveClangOpaqueTypeDefinition (clang_type);
return;
}
}
}
}
void
SymbolFileDWARFDebugMap::CompleteObjCInterfaceDecl (void *baton, clang::ObjCInterfaceDecl *decl)
{
SymbolFileDWARFDebugMap *symbol_file_dwarf = (SymbolFileDWARFDebugMap *)baton;
clang_type_t clang_type = symbol_file_dwarf->GetClangASTContext().GetTypeForDecl (decl);
if (clang_type)
{
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = symbol_file_dwarf->GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
if (oso_dwarf->HasForwardDeclForClangType (clang_type))
{
oso_dwarf->ResolveClangOpaqueTypeDefinition (clang_type);
return;
}
}
}
}
Adding the DWARF parser side for assited layout where the AST context will ask ExternalASTSource objects to help laying out a type. This is needed because the DWARF typically doesn't contain alignement or packing attribute values, and we need to be able to match up types that the compiler uses in expressions. llvm-svn: 149160
2012-01-28 08:48:57 +08:00
bool
SymbolFileDWARFDebugMap::LayoutRecordType (void *baton,
const clang::RecordDecl *record_decl,
uint64_t &size,
uint64_t &alignment,
llvm::DenseMap <const clang::FieldDecl *, uint64_t> &field_offsets,
llvm::DenseMap <const clang::CXXRecordDecl *, clang::CharUnits> &base_offsets,
llvm::DenseMap <const clang::CXXRecordDecl *, clang::CharUnits> &vbase_offsets)
{
SymbolFileDWARFDebugMap *symbol_file_dwarf = (SymbolFileDWARFDebugMap *)baton;
SymbolFileDWARF *oso_dwarf;
for (uint32_t oso_idx = 0; ((oso_dwarf = symbol_file_dwarf->GetSymbolFileByOSOIndex (oso_idx)) != NULL); ++oso_idx)
{
if (oso_dwarf->LayoutRecordType (record_decl, size, alignment, field_offsets, base_offsets, vbase_offsets))
return true;
}
return false;
}
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
clang::DeclContext*
SymbolFileDWARFDebugMap::GetClangDeclContextContainingTypeUID (lldb::user_id_t type_uid)
{
const uint64_t oso_idx = GetOSOIndexFromUserID (type_uid);
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
if (oso_dwarf)
return oso_dwarf->GetClangDeclContextContainingTypeUID (type_uid);
return NULL;
}
clang::DeclContext*
SymbolFileDWARFDebugMap::GetClangDeclContextForTypeUID (const lldb_private::SymbolContext &sc, lldb::user_id_t type_uid)
{
const uint64_t oso_idx = GetOSOIndexFromUserID (type_uid);
SymbolFileDWARF *oso_dwarf = GetSymbolFileByOSOIndex (oso_idx);
if (oso_dwarf)
return oso_dwarf->GetClangDeclContextForTypeUID (sc, type_uid);
return NULL;
}