History log of /external/lldb/source/Symbol/SymbolFile.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
7940069905bee0b2e5f0661bf37c9f906ddf8603 10-Jul-2013 Greg Clayton <gclayton@apple.com> Cleanup on the unified section list changes. Main changes are:
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.

Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185990 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
81a96aa6242f7b559770f5dc62316253cb8cb0d4 18-Apr-2013 Greg Clayton <gclayton@apple.com> Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
9e8865ee73f1c3decad554809368e8779b8c3e98 26-Apr-2012 Greg Clayton <gclayton@apple.com> Save more memory by not parsing the symbol table for stand alone DWARF files. We currently have SymbolFile plug-ins which all get the chance to say what they can parse in a symbol file. Prior to this fix we would ask the SymbolFileDWARF plug-in what abilities it had, and it would answer with "everything", and then we would check the SymbolFileSymtab plug-in what abilities it had, in case it had more abilities. The checking that SymbolFileSymtab does is a bit expensive as it pulls in the entire symbol table just to see if it can offer a few scraps of debug information. This causes all stand along DWARF files to pull in their symbol tables even though those symbols will never be used. This fix will check all SymbolFile plug-ins for their abilities and if any plug-in responds with "everything", then we stop the search.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155638 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
df6dc88322f103b263092d752db4490e628a1cbd 05-Jan-2012 Greg Clayton <gclayton@apple.com> Added code in the Host layer that can report system log messages
so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.

For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147596 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
75d8c2591f6c56a09338bf4967a41510165a907e 28-Nov-2011 Greg Clayton <gclayton@apple.com> CommandObjectProcess was recently changed to automatically use the platform
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this isn't supported. I added:

bool
Platform::CanDebugProcess ();

This will get checked before trying to launch a process for debugging and then
fall back to launching the process through the current host debugger. This
should solve the issue for linux and keep the platform code clean.

Centralized logging code for logging errors, warnings and logs when reporting
things for modules or symbol files. Both lldb_private::Module and
lldb_private::SymbolFile now have the following member functions:

void
LogMessage (Log *log, const char *format, ...);

void
ReportWarning (const char *format, ...);

void
ReportError (const char *format, ...);

These will all output the module name and object (if any) such as:

"error: lldb.so ...."
"warning: my_archive.a(foo.o) ...."

This will keep the output consistent and stop a lot of logging calls from
having to try and output all of the information that uniquely identifies
a module or symbol file. Many places in the code were grabbing the path to the
object file manually and if the module represented a .o file in an archive, we
would see log messages like:

error: foo.a - some error happened



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@145219 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
b01000fd063629facd45044f137446fb748ee179 17-Jan-2011 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123613 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
e98ac25604b3d967158917f6fdd5289b3096fd80 10-Nov-2010 Greg Clayton <gclayton@apple.com> 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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118672 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/SymbolFile.cpp
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


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