History log of /external/lldb/include/lldb/Symbol/CompileUnit.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/include/lldb/Symbol/CompileUnit.h
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/include/lldb/Symbol/CompileUnit.h
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
0be1edd34ff46e017b1b973c5a57e3de9f613baf 03-Apr-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11160171>

Fixed an issue where there were more than one way to get a CompileUnitSP created when using SymbolFileDWARF with SymbolFileDWARFDebugMap. This led to an assertion that would fire under certain conditions. Now there is only one way to create the compile unit and it will "do the right thing".



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153908 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
3508c387c3f0c9ecc439d98048fd7694d41bab1b 24-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10103468>

I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151336 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
d6d47976b71187907c1cdeea86fabf7d5534314f 23-Sep-2011 Jim Ingham <jingham@apple.com> Added the ability to restrict breakpoints by function name, function regexp, selector
etc to specific source files.
Added SB API's to specify these source files & also more than one module.
Added an "exact" option to CompileUnit's FindLineEntry API.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140362 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
c51ffbf896e398ada5f7e89b2fa5aec6f2224f09 12-Aug-2011 Greg Clayton <gclayton@apple.com> We were leaking a stack frame in StackFrameList in Thread.cpp which could
cause extra shared pointer references to one or more modules to be leaked.
This would cause many object files to stay around the life of LLDB, so after
a recompile and rexecution, we would keep adding more and more memory. After
fixing the leak, we found many cases where leaked stack frames were still
being used and causing crashes in the test suite. These are now all resolved.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137516 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
9488b7423b556c7c777b721d2094fd5ec4a47578 28-Jul-2010 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@109574 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
12bec71b323dc520f0e985a86e09c4712559e115 28-Jun-2010 Greg Clayton <gclayton@apple.com> Added function name types to allow us to set breakpoints by name more
intelligently. The four name types we currently have are:

eFunctionNameTypeFull = (1 << 1), // The function name.
// For C this is the same as just the name of the function
// For C++ this is the demangled version of the mangled name.
// For ObjC this is the full function signature with the + or
// - and the square brackets and the class and selector
eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class
// methods or selectors will be searched.
eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments
eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names


this allows much more flexibility when setting breakoints:

(lldb) breakpoint set --name main --basename
(lldb) breakpoint set --name main --fullname
(lldb) breakpoint set --name main --method
(lldb) breakpoint set --name main --selector

The default:

(lldb) breakpoint set --name main

will inspect the name "main" and look for any parens, or if the name starts
with "-[" or "+[" and if any are found then a full name search will happen.
Else a basename search will be the default.

Fixed some command option structures so not all options are required when they
shouldn't be.

Cleaned up the breakpoint output summary.

Made the "image lookup --address <addr>" output much more verbose so it shows
all the important symbol context results. Added a GetDescription method to
many of the SymbolContext objects for the more verbose output.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107075 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
e28824e0b988221c7eedf8e3d212527d2bdac6a7 09-Jun-2010 Eli Friedman <eli.friedman@gmail.com> And a few more warning/error fixes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/CompileUnit.h
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/include/lldb/Symbol/CompileUnit.h