7980d35608225dc71b3dd946d4c3aea85bc24e85 |
|
13-Jul-2013 |
Greg Clayton <gclayton@apple.com> |
Fixed GetModuleSpecifications() to work better overall: - MachO files now correctly extract the UUID all the time - More file size and offset verification done for universal mach-o files to watch for truncated files - ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files) - lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file - The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback - Improved printing for ModuleSpec objects git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186211 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
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/ObjectFile.cpp
|
a807ceef5dad2b24e5bae5c5a193ff03aa7ec8d9 |
|
01-Jul-2013 |
Michael Sartain <mikesart@valvesoftware.com> |
Split symbol support for ELF and Linux. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
97a19b21dacd9063bb5475812df7781777262198 |
|
29-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180717 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
36b877d2d27f7d1890f2d13807a3addb216648e2 |
|
25-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.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/ObjectFile.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/ObjectFile.cpp
|
00af72e395d138f459192b7f5450fa4c7854f135 |
|
03-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13384801> Make lldb_private::RegularExpression thread safe everywhere. This was done by removing the m_matches array from the lldb_private::RegularExpression class and putting it into the new lldb_private::RegularExpression::Match class. When executing a regular expression you now have the option to create a lldb_private::RegularExpression::Match object and pass a pointer in if you want to get parenthesized matching. If you don't want any matching, you pass in NULL. The lldb_private::RegularExpression::Match object is initialized with the number of matches you desire. Any matching strings are now extracted from the lldb_private::RegularExpression::Match objects. This makes the regular expression objects thread safe and as a result many more regex objects were turned into static objects that end up using a local lldb_private::RegularExpression::Match object when executing. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178702 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
952e9dc874944fcdbbb224f3ec4fc2c859376f64 |
|
28-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
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/source/Symbol/ObjectFile.cpp
|
0688435f443de94c82a1ec3b33451beaf2f0b43d |
|
27-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
Added eSymbolTypeResolver to a few switch statements that needed it. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176210 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
cbe61bd26db663fa3036866dc33315c6ffc37910 |
|
06-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13159777> lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174524 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
3cf7ab5462467121b4ac6cde09ee994030dad0c5 |
|
06-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11109570> The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
2ddb2b8aed6d43665c6955255f6a077574a08412 |
|
01-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13092722> Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD. Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match. Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174222 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
1e52600c9f14bc28b27e816d84b5f73ec01b392e |
|
05-Jan-2013 |
Sean Callanan <scallanan@apple.com> |
Read bytes from zero-filled sections correctly instead of failing to read. <rdar://problem/12958589> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@171552 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae |
|
29-Nov-2012 |
Daniel Malea <daniel.malea@intel.com> |
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
c9b798c06458466c818efc6b385f538a22fae022 |
|
28-Nov-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12639603> Simplify the logging on ObjectFile::~ObjectFile() to not access an classes above the object file (like the module) so we don't crash when logging object lifetimes. The log message contains the "this" pointer value which can be matched up with the constructor log. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168754 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
ef9eb809246491a7a9db1f2bd35d854924525ba6 |
|
11-Sep-2012 |
Jason Molenda <jmolenda@apple.com> |
Remove LLDB_DISABLE_PYTHON ifndef around FormatManager::LoadObjCFormatters() prototype, it is unconditionally present now. ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t. ObjectFile::FindPlugin ditto. DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163599 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
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/source/Symbol/ObjectFile.cpp
|
23d90aea32663f114ffee323775b02dad09f2f18 |
|
27-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
Fixed a few things in the ELF object file: 1 - sections only get a valid VM size if they have SHF_ALLOC in the section flags 2 - symbol names are marked as mangled if they start with "_Z" Also fixed the DWARF parser to correctly use the section file size when extracting the DWARF. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153496 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
0c31d3d3a4a1d00d53346d8a23b0519f47e55d1f |
|
07-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152244 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
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/source/Symbol/ObjectFile.cpp
|
3383c1741c6b0ea4648a019f89333ec73e632c5b |
|
21-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Fixed an issue where empty sections or zero filled sections could return incorrect values and also fire an assertion. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151066 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
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/source/Symbol/ObjectFile.cpp
|
b5a8f1498e1ddaeed5187a878d57ea0b74af9c26 |
|
05-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149804 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
13d24fb1817faa7ccc4cfd799113ba1a2b8968eb |
|
29-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
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). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
db2dc2b824b61ef7578dc8cdad7b338aa82b1f17 |
|
12-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
Big change in the way ObjectFile file contents are managed. We now mmap() the entire object file contents into memory with MAP_PRIVATE. We do this because object file contents can change on us and currently this helps alleviate this situation. It also make the code for accessing object file data much easier to manage and we don't end up opening the file, reading some data and closing the file over and over. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148017 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
3f69eacbb218a37390822c89d3675bd740590382 |
|
03-Dec-2011 |
Greg Clayton <gclayton@apple.com> |
Added new symbol types for Objective C classes, metaclasses, and ivars. Each object file can correctly make these symbols which will abstract us from the file format and ABI and we can then ask for the objective C class symbol for a class and find out which object file it was defined in. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@145744 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
a1b9a90b7aef446302de9b845dc4f3b0e1473aa7 |
|
13-Nov-2011 |
Greg Clayton <gclayton@apple.com> |
<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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144489 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
24a6bd9835ed1655984397b0cdf35127e47681e9 |
|
27-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143114 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
00db215522a0cf31082d26d7ab30d2aa30965acf |
|
05-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Enable all the new accelerator tables if they are present and don't manually index the DWARF. Also fixed an issue with memory accelerator tables with a size of 1 where we would loop infinitely. Added support for parsing the new .apple_namespaces section which gives us a memory hash table for looking up namespaces. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141128 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
f6e3de2d877dc94120c72624a79e488c9bea5c35 |
|
28-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
Convert over to the latest and greatest on disc accelerator hash tables. Renamed the DWARF sections to ".apple_names" and ".apple_types" until we get more buy in from other vendors. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140702 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
e40b6424d9e49306392bec4b44060da36414c382 |
|
18-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140002 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
c8cf5e234be554d4acb6ae644a8269c303c4f56e |
|
02-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
Added support for accessing and loading our new .debug_names and .debug_types DWARF accelerator table sections to the DWARF parser. These sections are similar to the .debug_pubnames and .debug_pubtypes, but they are designed to be hash tables that are saved to disc in a way that the sections can just be loaded into memory and used without any work on the debugger side. The .debug_pubnames and .debug_pubtypes sections are not ordered, contain a copy of the name in the section itself which makes these sections quite large, they only include publicly exported names (so no static functions, no types defined inside functions), many compilers put different information in them making them very unreliable so most debugger ignore these sections and parse the DWARF on their own. The tables must also be parsed and sorted in order to be used effectively. The new sections can be quickly loaded and very efficiently be used to do name to DIE lookups with very little up front work. The format of these new sections will be changing while we work out the bugs, but we hope to have really fast name to DIE lookups soon. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138979 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
b72d0f098e45936fa72e26b1a026c603e17e2d6c |
|
12-Apr-2011 |
Greg Clayton <gclayton@apple.com> |
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
b344843f75ef893762c93fd0a22d2d45712ce74d |
|
24-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128239 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
b1888f24fa181489840b9acf193e224d125d0776 |
|
19-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127934 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
89e4bae3cbb26e566dbbff1e717c95385d126c48 |
|
05-Nov-2010 |
Johnny Chen <johnny.chen@apple.com> |
Fix the infinite recursion crash reported by Antoine Missout: rdar://problem/8557095 lldb disas crashed (from lldb developer) git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118299 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
537a7a86687683fd403ce652d178fbc89e06ef9f |
|
20-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116944 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.cpp
|
7508e732818c32e1cfeaaf7d1d507fe3834ce9d2 |
|
10-Aug-2010 |
Jim Ingham <jingham@apple.com> |
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@110624 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/ObjectFile.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/ObjectFile.cpp
|