History log of /external/lldb/include/lldb/Core/RangeMap.h
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/include/lldb/Core/RangeMap.h
2d63ae1820e622335caf58f86a86164a2a160931 22-Mar-2013 Jason Molenda <jmolenda@apple.com> Add a Reserve method to RangeVector and RangeDataVector. Have the
DWARFCallFrameInfo method which returns a RangeVector pre-size the
vector based on the number of entries it will be adding insted of
growing the vector as items are added.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177773 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
464a5063bc59755cb6ec063d0b2491097302d2ab 04-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13338643>

DWARF with .o files now uses 40-60% less memory!

Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
- Lazily parse the debug map for each object file
- not require the address map for a .o file until debug information is linked for a .o file



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176454 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
4aa2edf602fa60693afa33d4fe0d1d459a488333 09-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11016907>

Get function boundaries from the LC_FUNCTION_STARTS load command. This helps to determine symbol sizes and also allows us to be able to debug stripped binaries.

If you have a stack backtrace that goes through a function that has been stripped from the symbol table, the variables for any functions above that stack frame will most likely be incorrect. It can also affect our ability to step in/out/through of a function.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152381 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
761133029ba2d5bb0c21c3a871dede340b2775fc 22-Feb-2012 Greg Clayton <gclayton@apple.com> For stepping performance I added the ability to outlaw all memory accesseses
to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't
slide __PAGEZERO and it also registers it as an invalid region of memory. This
allows us to not make any memory requests from the local or remote debug session
for any addresses in this region. Stepping performance can improve when uninitialized
local variables that point to locations in __PAGEZERO are attempted to be read
from memory as we won't even make the memory read or write request.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151128 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
46c9a355af9b39db78c006b2a5cbf97d3c58d947 09-Feb-2012 Greg Clayton <gclayton@apple.com> First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
be42123fa214b039b86ad152bd21d910db7a7af2 08-Oct-2011 Greg Clayton <gclayton@apple.com> Changed RangeMap over to use llvm::SmallVector and updated the RangeArray and the RangeDataArray to have an extra "unsigned N" template parameter. Updated the lldb_private::Block to use a RangeArray with a uint32_t for both the function base offset and block range size, and then a 1 for the small vector size since most lexical blocks in DWARF only have 1 range. Updates the DWARFDebugRanges RangeArray to use an unsigned of 2 since most blocks that have more than one range usually have 2. Also updated a DWARFDebugAranges to default their RangeArray to use a SmallVector with unsigned size of 1 since this will take care of the .o files when doing DWARF in .o files and since there really isn't any good size we can guess with.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141480 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
c03a99ae9cced3e3086f10db444ddc90d115a3f3 08-Oct-2011 Greg Clayton <gclayton@apple.com> Added some debug code that can verify that all RangeMap.h maps are sorted when needed since RangeArray and RangeDataArray instantiations depend on it. I ran the test suite with ASSERT_RANGEMAP_ARE_SORTED defined and I got no assertions, so I disabled it prior to checkin.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141478 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
bc36a861b8e0b2f2dde34f27c9fa9629a357d598 08-Oct-2011 Greg Clayton <gclayton@apple.com> Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141460 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
61aca5dd78f07de66e997d41af521ab9d8c16b89 07-Oct-2011 Greg Clayton <gclayton@apple.com> Re-organized the contents of RangeMap.h to be more concise and also allow for a Range, RangeArray, RangeData (range + data), or a RangeDataArray. We have many range implementations in LLDB and I will be converting over to using the classes in RangeMap.h so we can have one set of code that does ranges and searching of ranges.

Fixed up DWARFDebugAranges to use the new range classes.

Fixed the enumeration parsing to take a lldb_private::Error to avoid a lot of duplicated code. Now when an invalid enumeration is supplied, an error will be returned and that error will contain a list of the valid enumeration values.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141382 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h
257663e753af15633e48c7b00eb7b5880168090b 07-Oct-2011 Greg Clayton <gclayton@apple.com> Since we use address ranges a lot I added a templatized class that allows us to easily control the base address type, the size type, and the data that is stored with each range. It is designed to be populated by appending all needed items, then sorting the resulting list, and optionally minimizing the list when done. I adopted this new list in the DWARFDebugAranges for even further memory savings.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141352 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/RangeMap.h