summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/Mach-O
Commit message (Collapse)AuthorAgeFilesLines
...
* Removed the == and != operators from ArchSpec, sinceSean Callanan2012-12-131-1/+1
| | | | | | | | | | | | equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
* Remove insufficient linkedit address check; the problemJason Molenda2012-12-131-1/+1
| | | | | | | | is deeper than that and avoiding the crash in this one part of code won't solve anything. I know where the real problem is now. llvm-svn: 170068
* <rdar://problem/12831670>Jason Molenda2012-12-071-1/+1
| | | | | | | | | | When using the same-device optimization for shared cache libraries, if we have an invalid load address for __LINKEDIT, don't try to read anything out of lldb's own address space. Reading it out of the remote address space will fail gracefully if we have bad addresses but reading it out of lldb's own address space will result in a crash. llvm-svn: 169582
* <rdar://problem/12106825>Greg Clayton2012-11-271-77/+88
| | | | | | Allow the expression parser to see more than just data symbols. We now accept any symbol that has an address. We take precautions to only accept symbols by their mangled or demangled names only if the demangled name was not synthesized. If the demangled name is synthesized, then we now mark symbols accordingly and only compare against the mangled original name. llvm-svn: 168668
* <rdar://problem/12238339> Greg Clayton2012-11-161-0/+5
| | | | | | Make sure architectures are obeyed for skinny mach files. llvm-svn: 168205
* <rdar://problem/12602978>Greg Clayton2012-10-301-1/+13
| | | | | | RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions. llvm-svn: 167066
* Bunch of cleanups for warnings found by the llvm static analyzer.Jim Ingham2012-10-121-16/+19
| | | | llvm-svn: 165808
* Train LLDB to deal with bad linker N_SO entries that point to our source ↵Greg Clayton2012-09-071-0/+36
| | | | | | files for debug map + DWARF in .o file debugging. llvm-svn: 163417
* <rdar://problem/12237556>Greg Clayton2012-09-051-31/+40
| | | | | | Fixed an issue where we didn't parse N_SO stab pairs where the first N_SO was a relative path. llvm-svn: 163259
* <rdar://problem/12100588>Greg Clayton2012-09-051-1/+7
| | | | | | Don't crash when we can't resolve our stub to a symbol. llvm-svn: 163189
* Removed explicit NULL checks for shared pointersSean Callanan2012-08-091-2/+2
| | | | | | | | | and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
* Change the things we pass to Mangled::SetValue to be ConstStrings instead of Jason Molenda2012-07-201-5/+5
| | | | | | char*'s - Greg removed the methods which accept char*'s earlier today. llvm-svn: 160539
* Cleaned up the lldb_private::Mangled class to get rid of the tokenizing code ↵Greg Clayton2012-07-181-6/+6
| | | | | | that has bit rotted and isn't being used. Also cleaned up the API to the "lldb_private::Mangled" to always take "const ConstString &" arguments instead of both "const ConstString &" and "const char *". llvm-svn: 160466
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-5/+0
| | | | llvm-svn: 160338
* Blacklisted a UUID that is generated by OpenCL onSean Callanan2012-07-121-0/+13
| | | | | | | | | | Mac OS X, because the UUID is the same for all OpenCL-generated dylibs and therefore would conflict. <rdar://problem/11620586> llvm-svn: 160135
* Additional comment in ObjectFileMachO::ParseSymtab to explainJason Molenda2012-06-221-6/+14
| | | | | | | the layout of the dyld shared cache file and how we're stepping through it; also use offsetof to find offsets of struct elements. llvm-svn: 158962
* Preliminary set of changes to ObjectFileMachO::ParseSymtab when lldbJason Molenda2012-06-211-8/+847
| | | | | | | | | | | | | | | | | is being run on iOS natively and we are examining a binary that is in the shared-cache. The shared cache may be set up to not load the symbol names in memory (and may be missing some local symbols entirely, to boot) so we need to read the on-disk-but-not-mapped-into-memory cache of symbol names/symbols before we start processing the in-memory nlist entries. This code needs to be reorganized into its own separate method, ideally we'll find some way to not duplicate the nlist symbol handling. But we need to handle this new format quickly and we'll clean up later. Thanks for James McIlree for the patch. Fixes <rdar://problem/11639018>. llvm-svn: 158891
* Committed a change to the SectionList that introducesSean Callanan2012-06-081-1/+1
| | | | | | | | | | | a cache of address ranges for child sections, accelerating lookups. This cache is built during object file loading, and is then set in stone once the object files are done loading. (In Debug builds, we ensure that the cache is never invalidated after that.) llvm-svn: 158188
* <rdar://problem/11537498>Greg Clayton2012-05-301-2/+20
| | | | | | | | | | | | | | | | | Fixed an issue with the symbol table parsing of files that have STAB entries in them where there are two N_SO entries where the first has a directory, and the second contains a full path: [ 0] 00000002 64 (N_SO ) 00 0000 0000000000000000 '/Volumes/data/src/' [ 1] 0000001e 64 (N_SO ) 00 0000 0000000000000000 '/Volumes/data/src/Source/main.m' [ 2] 00000047 66 (N_OSO ) 09 0001 000000004fc642d2 '/tmp/main.o' [ 3] 00000001 2e (N_BNSYM ) 01 0000 0000000000003864 [ 4] 000000bd 24 (N_FUN ) 01 0000 0000000000003864 '_main' [ 5] 00000001 24 (N_FUN ) 00 0000 00000000000000ae [ 6] 00000001 4e (N_ENSYM ) 01 0000 00000000000000ae [ 7] 00000001 64 (N_SO ) 01 0000 0000000000000000 We now correctly combine entries 0 and 1 into a single entry. llvm-svn: 157712
* <rdar://problem/11535465> Greg Clayton2012-05-251-8/+15
| | | | | | LC_ENCRYPTION_INFO with "cryptid == 0" is not actually encrypted and LLDB fails to read memory from file. llvm-svn: 157487
* Fixed an issue where we might have easy access to the string table data for ↵Greg Clayton2012-05-251-17/+21
| | | | | | a mach file from memory even though we have a process. So now we don't read the string table strings from memory when we don't have to. llvm-svn: 157482
* Found a quick way to improve the speed with which we can read object files ↵Greg Clayton2012-05-181-23/+48
| | | | | | from memory when they are in the shared cache: always read the symbol table strings from memory and let the process' memory cache do the work. llvm-svn: 157083
* Added support for the LC_ENCRYPTION_INFO load command.Greg Clayton2012-04-241-2/+28
| | | | llvm-svn: 155423
* A small fix for ObjectFileMachO::ParseSymtab() where a pointerJason Molenda2012-04-241-1/+5
| | | | | | | | into the middle of a vector was being used after the vector may have been resized. <rdar://problem/11284937> llvm-svn: 155421
* Added an iOS local debugging optimization when reading the __LINKEDIT ↵Greg Clayton2012-04-181-11/+51
| | | | | | section data for files in the dyld shared cache. llvm-svn: 154984
* Expose GetAddressClass() from both the SBAddress and SBInstruction so ↵Greg Clayton2012-04-131-1/+1
| | | | | | clients can tell the difference between ARM/Thumb opcodes when disassembling ARM. llvm-svn: 154633
* <rdar://problem/11042408>Greg Clayton2012-03-141-7/+49
| | | | | | | | Fixed an issue with the FUNC_STARTS load command where we would get the symbol size wrong and we would add all sorts of symbols due to bit zero being set to indicate thumb. llvm-svn: 152696
* <rdar://problem/11034170> Greg Clayton2012-03-132-307/+347
| | | | | | | | | | | | | | | | | | | Simplify the locking strategy for Module and its owned objects to always use the Module's mutex to avoid A/B deadlocks. We had a case where a symbol vendor was locking itself and then calling a function that would try to get it's Module's mutex and at the same time another thread had the Module mutex that was trying to get the SymbolVendor mutex. Now any classes that inherit from ModuleChild should use the module lock using code like: void ModuleChildSubclass::Function { ModuleSP module_sp(GetModule()); if (module_sp) { lldb_private::Mutex::Locker locker(module_sp->GetMutex()); ... do work here... } } This will help avoid deadlocks by using as few locks as possible for a module and all its child objects and also enforce detecting if a module has gone away (the ModuleSP will be returned empty if the weak_ptr does refer to a valid object anymore). llvm-svn: 152679
* <rdar://problem/11016907>Greg Clayton2012-03-091-730/+871
| | | | | | | | 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. llvm-svn: 152381
* Updated the revision of LLVM/Clang used by LLDB.Sean Callanan2012-03-081-0/+11
| | | | | | | | | | | | | | | This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
* <rdar://problem/10997402>Greg Clayton2012-03-071-12/+11
| | | | | | | | | | | 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. llvm-svn: 152244
* <rdar://problem/10103468>Greg Clayton2012-02-242-65/+73
| | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 151336
* Added the ability to get a ObjectFile versions from the ObjectFileGreg Clayton2012-02-222-0/+54
| | | | | | | subclasses if the object files support version numbering. Exposed this through SBModule for upcoming data formatter version checking stuff. llvm-svn: 151190
* Full core file support has been added for mach-o core files.Greg Clayton2012-02-131-36/+251
| | | | | | | | | | | | | | | | Tracking modules down when you have a UUID and a path has been improved. DynamicLoaderDarwinKernel no longer parses mach-o load commands and it now uses the memory based modules now that we can load modules from memory. Added a target setting named "target.exec-search-paths" which can be used to supply a list of directories to use when trying to look for executables. This allows one or more directories to be used when searching for modules that may not exist in the SDK/PDK. The target automatically adds the directory for the main executable to this list so this should help us in tracking down shared libraries and other binaries. llvm-svn: 150426
* Improved detection of object file types, movingSean Callanan2012-02-101-2/+14
| | | | | | | | | | detection of kernels into the object file and adding a new category for raw binary images. Fixed all clients who previously searched for sections manually, making them use the object file's facilities instead. llvm-svn: 150272
* First pass at mach-o core file support is in. It currently works for x86_64 Greg Clayton2012-02-092-5/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 150154
* <rdar://problem/10560053>Greg Clayton2012-02-052-10/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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". llvm-svn: 149804
* Big change in the way ObjectFile file contents are managed. We nowGreg Clayton2012-01-122-35/+21
| | | | | | | | | | 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. llvm-svn: 148017
* Added code in the Host layer that can report system log messagesGreg Clayton2012-01-051-8/+9
| | | | | | | | | | | | 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. llvm-svn: 147596
* <rdar://problem/10368163>Greg Clayton2011-12-301-30/+72
| | | | | | | | Watch for empty symbol tables by doing a lot more error checking on all mach-o symbol table load command values and data that is obtained. This avoids a crash that was happening when there was no string table. llvm-svn: 147358
* Fix a bug where when debugging with .o files, we end up with two symbols for ↵Jim Ingham2011-12-161-4/+20
| | | | | | | | each real OBJC_CLASS_$_whatever, one of which is correctly classified as an ObjCClass symbol, and the other is just a data symbol. This was messing up the ObjC dynamic type detection. <rdar://problem/10589527> llvm-svn: 146712
* Testcase fixes with the new symbol lookup code forSean Callanan2011-12-031-3/+3
| | | | | | | | | | | | 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
* Remove accidental "else" that was left in in prior checking.Greg Clayton2011-12-031-1/+1
| | | | llvm-svn: 145746
* Added new symbol types for Objective C classes, metaclasses, and ivars. EachGreg Clayton2011-12-031-85/+136
| | | | | | | | 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. llvm-svn: 145744
* 12% allocated memory savings when debugging clang with DWARF in .o files byGreg Clayton2011-11-221-0/+3
| | | | | | making sure we perfectly size our vector of symbols on the symbol table. llvm-svn: 145069
* <rdar://problem/10338439>Greg Clayton2011-11-131-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/10368163>Greg Clayton2011-10-311-2/+15
| | | | | | | | Fixed an issue where if a mach-o symbol table was corrupt and had a string table offset that is invalid, we could crash. We now properly check the string table offset and ignore any symbols with invalid strings. llvm-svn: 143362
* Added support for the new ".apple_objc" accelerator tables. These tables areGreg Clayton2011-10-271-26/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 143114
* Removed namespace qualification from symbol queries.Sean Callanan2011-10-131-1/+1
| | | | llvm-svn: 141866
* Added ClangNamespaceDecl * parameters to severalSean Callanan2011-10-121-1/+2
| | | | | | | core Module functions that the expression parser will soon be using. llvm-svn: 141766
OpenPOWER on IntegriCloud