summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/Mach-O
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement ObjectFileMachO::SetLoadAddress().Greg Clayton2014-02-062-0/+59
| | | | llvm-svn: 200943
* If a library has no N_FUN symbols we don't succeed in finding resolver ↵Greg Clayton2014-01-161-2/+2
| | | | | | | | symbols, now we do. <rdar://problem/15831334> llvm-svn: 199345
* Make sure we correctly merge all N_FUN symbols with non-stab entries even if ↵Greg Clayton2014-01-161-50/+82
| | | | | | | | there are multiple symbols with the same name. <rdar://problem/15831292> llvm-svn: 199344
* The actual indirect symbol is not the one at the address of the Trie entry ↵Jim Ingham2014-01-101-27/+42
| | | | | | marked with the EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER, it is given in the address in the “other” field in that entry. llvm-svn: 198967
* Added the ability to get the SDK path for a target using the platform ↵Greg Clayton2013-10-242-0/+132
| | | | | | | | plugins. If LLDB lives inside an Xcode.app bundle, it will select the SDK in the Xcode bundle, else it will use the currently selected Xcode. Also added the DWARFDataExtractor classes to the Xcode project file. llvm-svn: 193380
* <rdar://problem/14496092>Greg Clayton2013-10-211-35/+240
| | | | | | | | Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name. Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to. llvm-svn: 193101
* <rdar://problem/15191078>Greg Clayton2013-10-111-1/+1
| | | | | | Fixed Module::ResolveSymbolContextForAddress() to be able to also look in the SymbolVendor's SymbolFile's ObjectFile for a more meaningful symbol when a symbol lookup finds a synthetic symbol from the main object file. This will help lookups on MacOSX as the main executable might be stripped, but the dSYM file always has a full symbol table. llvm-svn: 192510
* Convert to UNIX line endings.Joerg Sonnenberger2013-09-251-5/+5
| | | | llvm-svn: 191367
* Change ProcessMachCore to search for both a user-process dyld binaryJason Molenda2013-09-141-2/+2
| | | | | | | | | | | | | | | | and a mach kernel in all the pages of the core file. If it finds a user-process dyld binary, assume this is a user process that had a copy of the mach kernel in memory when it crashed (e.g. lldb doing kernel debugging) even though we found the kernel binary first. Also, change the error messages about sections extending past the end of the file to be warnings and make the messages sound less severe. Most user process core files have one section that isn't included in the file and there's no reason to worry people about that. <rdar://problem/14473235> llvm-svn: 190741
* Fixed a few typos.Ashok Thirumurthi2013-08-271-2/+2
| | | | llvm-svn: 189355
* Fix some names in the wake of my Mach-O changes to LLVM.Charles Davis2013-08-271-282/+277
| | | | llvm-svn: 189317
* When ObjectFileMachO::GetModuleSpecifications is getting the ArchSpecJason Molenda2013-08-271-0/+5
| | | | | | | | | out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't let the OS be set to "ios" or "macosx" - there will be no dynamic loader used when debugging this process. <rdar://problem/9956443> llvm-svn: 189305
* MingW compilation (windows). Includes various refactoring to improve ↵Virgile Bello2013-08-231-1/+1
| | | | | | portability. llvm-svn: 189107
* Follow-up to the checkin of r188532 -- make sure thatJason Molenda2013-08-171-0/+9
| | | | | | | we've read the ObjectFile's Symtab before we change the File addresses in the Sections. llvm-svn: 188604
* Add a new Section::SetFileAddress method to change a Section's fileJason Molenda2013-08-161-10/+24
| | | | | | | | | | | | | | | | | | | | | address. When loading a dSYM, and the file addresses of the dSYM Sections are different than the executable binary Sections' file addresses, the debug info won't be remapped to the actual load addresses correctly. This only happens with binaries on the in-memory shared cache binaries where their File addresses have been set to their actual load address (outside an offset value) whereas the original executable and dSYM have 0-based File addresses. I think this patch will not be activated for other cases -- this is the only case we know of where the dSYM and the executable's File addresses differ -- but if this causes other problems we can restrict it more carefully. <rdar://problem/12335086> llvm-svn: 188532
* <rdar://problem/14717184>Greg Clayton2013-08-131-1/+11
| | | | | | Improve the documentation for the new target.memory-module-load-level setting, and also return an error when there is no nlist data when appropriate. llvm-svn: 188317
* <rdar://problem/14717184>Greg Clayton2013-08-131-639/+648
| | | | | | | | | | | | LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting: (lldb) settings set target.memory-module-load-level [minimal|partial|complete] minimal will load only sections (no symbols, or function bounds via function starts or EH frame) partial will load sections + bounds complete will load sections + bounds + symbols llvm-svn: 188246
* Fixed GetModuleSpecifications() to work better overall:Greg Clayton2013-07-121-1/+2
| | | | | | | | | | | - 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 llvm-svn: 186211
* Cleanup on the unified section list changes. Main changes are:Greg Clayton2013-07-102-462/+471
| | | | | | | | | | | | | | | - 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) llvm-svn: 185990
* Split symbol support for ELF and Linux.Michael Sartain2013-07-012-3/+10
| | | | llvm-svn: 185366
* <rdar://problem/13941992>Greg Clayton2013-06-041-5/+7
| | | | | | Accept mach-o files with bad segments. Many core files are not created correctly and we should still be able to glean any information we can from them. llvm-svn: 183247
* <rdar://problem/13128331>Greg Clayton2013-05-151-24/+21
| | | | | | | | Fixed "target symbols add" to correctly extract all module specifications from a dSYM file that is supplied and match the symbol file to a current target module using the UUID values if they are available. This fixes the case where you add a dSYM file (like "foo.dSYM") which is for a renamed executable (like "bar"). In our case it was "mach_kernel.dSYM" which didn't match "mach_kernel.sys". llvm-svn: 181916
* <rdar://problem/13748253>Greg Clayton2013-05-141-91/+141
| | | | | | Combine N_GSYM stab entries with their non-stab counterpart (data symbols) to make the symbol table smaller with less duplicate named symbols. llvm-svn: 181841
* A few more small tweaks to arm core file handling.Jason Molenda2013-05-141-7/+20
| | | | | | | | | | | | Most importantly, have DoReadGPR/DoReadFPU/DoReadEXC return -1 to indicate failure if they're called. Else these could override the Error setting for the relevant thread state -- if the core file didn't include a floating point thread state, for instance, these functions would clear the Error setting for that register set and lldb would display random bytes as those registers' contents. <rdar://problem/13665075> llvm-svn: 181757
* Small change to the previous checkin, read in the fpu register contextJason Molenda2013-05-141-4/+10
| | | | | | | in one large block - and be sure toget the fpscr value as well when processing a core file. llvm-svn: 181756
* Fixes to read the floating point and exception registers sets outJason Molenda2013-05-141-18/+36
| | | | | | | of arm Mach-O core files. <rdar://problem/13665075> llvm-svn: 181755
* <rdar://problem/13854277>Greg Clayton2013-05-102-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* Cleanup logging to use the new "std::string FileSpec::GetPath()" function. ↵Greg Clayton2013-04-291-6/+4
| | | | | | | | | | | 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. llvm-svn: 180717
* Added the ability to extract a ModuleSpecList (a new class) from an ↵Greg Clayton2013-04-242-35/+164
| | | | | | | | | | | | | | | | | 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. llvm-svn: 180224
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-2/+2
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-2/+2
| | | | | | | | 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. llvm-svn: 179779
* Fix build on LinuxDaniel Malea2013-04-171-0/+4
| | | | | | | - add a workaround header to define uuid_t on platforms that need it - unbreak remote debugging of mac os x apps llvm-svn: 179710
* Fix a pointer arithmetic thinko in ObjectFileMachO::GetLLDBSharedCacheUUID().Jason Molenda2013-04-161-1/+1
| | | | llvm-svn: 179643
* Add warning messages for the cases where the inferior process shared cacheJason Molenda2013-04-161-5/+10
| | | | | | | | | differs from lldb's own shared cache, and where the inferior process shared cache does not match up with the on-disk shared cache file. Simplify the code where lldb gets its own shared cache uuid a little bit. llvm-svn: 179633
* <rdar://problem/13468295>Greg Clayton2013-04-161-13/+24
| | | | | | Show an error message when we have a corrupt mach-o file where the LC_SEGMENT or LC_SEGMENT_64 load command have file offsets or file offsets + sizes that extend beyond the end of the file. llvm-svn: 179605
* The dyld_all_image_infos structure, at version 13 and higher, hasJason Molenda2013-04-162-13/+127
| | | | | | | | | | | | a UUID for the shared cache libraries that can be used to confirm that one process' shared cache is the same as another, or that a process' in-memory shared cache is a match for a given on-disk dyld_shared_cache binary file. Use these UUIDs to catch some uncommon problems when the shared caches are being changed for debug purposes. <rdar://problem/13524467> llvm-svn: 179583
* Fix some minor code indentation mistakes in ObjectFileMachO.Jason Molenda2013-04-161-39/+39
| | | | | | No code changes in this checkin, only whitespace. llvm-svn: 179579
* When ObjectFileMachO::ParseSections() notices that it has a truncated file, ↵Jason Molenda2013-04-101-0/+26
| | | | | | | | | | | zero out the SectionList so we don't try to do anything with this file. Currently we end up crashing later in the debug session when we read past the end of the file -- this at least gets us closer with something like ProcessMachCore printing "error: core file has no sections". <rdar://problem/13468295> llvm-svn: 179152
* <rdar://problem/13521159>Greg Clayton2013-03-271-8/+8
| | | | | | | | 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. llvm-svn: 178191
* Don't try to read the eh_frame section out of a dSYM.Jason Molenda2013-03-221-1/+5
| | | | | | It won't have one and it isn't needed. llvm-svn: 177688
* Add a new method GetFunctionAddressAndSizeVector to DWARFCallFrameInfo.Jason Molenda2013-03-211-0/+33
| | | | | | | | | | | | | | | | | | | | | | | This returns a vector of <file address, size> entries for all of the functions in the module that have an eh_frame FDE. Update ObjectFileMachO to use the eh_frame FDE function addresses if the LC_FUNCTION_STARTS section is missing, to fill in the start addresses of any symbols that have been stripped from the binary. Generally speaking, lldb works best if it knows the actual start address of every function in a module - it's especially important for unwinding, where lldb inspects the instructions in the prologue of the function. In a stripped binary, it is deprived of this information and it reduces the quality of our unwinds and saved register retrieval. Other ObjectFile users may want to use the function addresses from DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO does already. <rdar://problem/13365659> llvm-svn: 177624
* Remove some tabs and extraneous space chars from ObjectFileMachO.cpp.Jason Molenda2013-03-061-136/+136
| | | | | | Noticed these while working on the last commit. llvm-svn: 176590
* Retrieve the dyld shared cache mapping offset from the shared cache instead ↵Jason Molenda2013-03-061-14/+64
| | | | | | | | | of hardcoding the value. Read the version number of the dyld shared cache. <rdar://problem/13311882> llvm-svn: 176589
* <rdar://problem/13338643>Greg Clayton2013-03-042-7/+1
| | | | | | | | | | | | | | | | 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 llvm-svn: 176454
* Added eSymbolTypeResolver to a few switch statements that needed it.Greg Clayton2013-02-271-0/+1
| | | | llvm-svn: 176210
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+5
| | | | | | | | | | | | | | - generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
* <rdar://problem/13159777> Greg Clayton2013-02-062-16/+39
| | | | | | | | | | | | | | 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. llvm-svn: 174524
* Change ObjectFileMachO::ParseSymtab to read the externalJason Molenda2013-02-051-2/+14
| | | | | | | | | function stub routine addresses from an in-memory-only MachO object file. This was the only remaining part of ParseSymtab() that was assuming a file exists. <rdar://problem/13139585> llvm-svn: 174455
* One more change of a uint32_t variable to offset_tJason Molenda2013-01-261-1/+1
| | | | | | | to match Greg's dataextractor patch, this one in some #if defined arm code. llvm-svn: 173564
* <rdar://problem/13069948>Greg Clayton2013-01-252-34/+35
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
OpenPOWER on IntegriCloud