summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/Mach-O
Commit message (Collapse)AuthorAgeFilesLines
...
* The llvm Triple for an armv6m now comes back as llvm::Triple::thumb.Jason Molenda2015-08-211-0/+1
| | | | | | | | | | | | | | This was breaking disassembly for arm machines that we force to be thumb mode all the time because we were only checking for llvm::Triple::arm. i.e. armv6m (ARM Cortex-M0) armv7m (ARM Cortex-M3) armv7em (ARM Cortex-M4) <rdar://problem/22334522> llvm-svn: 245645
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
* Make sure we detect symbols in the new __DATA_DIRTY and __DATA_CONST ↵Greg Clayton2015-07-272-2/+26
| | | | | | | | segments and classify them correctly. <rdar://problem/20942073> llvm-svn: 243344
* Make sure we calculate resolver symbol addresses correctly for ARM. The trie ↵Greg Clayton2015-07-161-8/+14
| | | | | | | | entries have bit 0 set for Thumb functions and we need to remove that so we can correctly determine which symbols are resolvers. <rdar://problem/21396553> llvm-svn: 242435
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-5/+5
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Check to make sure we have a valid N_GSYM symbol name before we use it for ↵Greg Clayton2015-07-011-29/+45
| | | | | | anything. llvm-svn: 241210
* Re-enable 'process save-core' for arm64 targets.Jason Molenda2015-06-251-5/+1
| | | | | | | | | Whatever problem I saw that caused me to disable this initially is not a problem today. <rdar://problem/21173317> <rdar://problem/20266253> llvm-svn: 240737
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-12/+12
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* If we have a MachO file loaded from memory, make sure we can always get the ↵Greg Clayton2015-06-082-53/+92
| | | | | | | | symbol table even if we don't have the __LINKEDIT load address set in the target. <rdar://problem/21208168> llvm-svn: 239354
* Fix LLDB so that it can correctly track down dependent shared libraries that ↵Greg Clayton2015-06-021-7/+62
| | | | | | | | use @rpath. <rdar://problem/8371885> llvm-svn: 238886
* Handle LC_ENCRYPTION_64 in addition to LC_ENCRYPTION load commands inJason Molenda2015-04-021-1/+3
| | | | | | | Mach-O files. <rdar://problem/20113673> llvm-svn: 233893
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-1/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Add Utility/ModuleCache class and integrate it with PlatformGDBRemoteServer ↵Oleksiy Vyalov2015-03-101-1/+2
| | | | | | | | - in order to allow modules caching from remote targets. http://reviews.llvm.org/D8037 llvm-svn: 231734
* Further reduce the header footprint of Process.hZachary Turner2015-03-031-0/+1
| | | | | | | No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
* Fix a crasher where we might have a N_UNDF symbol with no name and this ↵Greg Clayton2015-03-031-0/+2
| | | | | | | | could cause ObjectFileMachO::ParseSymtab() to crash. <rdar://problem/19989491> llvm-svn: 231048
* MacOSX symbol table change to combine the N_GSYM debug map entry with the ↵Greg Clayton2015-02-251-28/+74
| | | | | | "_OBJC_CLASS_$_", "_OBJC_METACLASS_$_", and "_OBJC_IVAR_$_" non debug symbols. This allows the symbol that represents the object file to contain the eSymbolTypeObjCClass and eSymbolTypeObjCMetaClass and will help us to be able to efficiently lookup the real definition of an objective C class without loading all .o files linearly to find the .o file that contains the true definition. llvm-svn: 230509
* Avoid crashing by not mmap'ing files on network mounted file systems.Greg Clayton2015-02-231-5/+5
| | | | | | | | | | | | | | | | | | | | This is implemented by making a new FileSystem function: bool FileSystem::IsLocal(const FileSpec &spec) Then using this in a new function: DataBufferSP FileSpec::MemoryMapFileContentsIfLocal(off_t file_offset, size_t file_size) const; This function only mmaps data if the file is a local file since that means we can reliably page in data. We were experiencing crashes where people would use debug info files on network mounted file systems and that mount would go away and cause the next access to a page that wasn't paged in to crash LLDB. We now avoid this by just copying the data into a heap buffer and keeping a permanent copy to avoid the crash. Updated all previous users of FileSpec::MemoryMapFileContentsIfLocal() in ObjectFile subclasses over to use the new FileSpec::MemoryMapFileContentsIfLocal() function. <rdar://problem/19470249> llvm-svn: 230283
* Make sure things build for iOS after recent changes.Greg Clayton2015-02-201-7/+9
| | | | llvm-svn: 230076
* Correctly handle N_INDR nlist entries and don't rely on the trie information ↵Greg Clayton2015-02-141-20/+108
| | | | | | | | in order to reproduce them since this dyld trie info can be missing. <rdar://problem/19749670> llvm-svn: 229201
* Don't wait for the dynamic loader to set a module as a dynamic link editor, ↵Greg Clayton2015-02-052-1/+10
| | | | | | | | | | figure it out through the ObjectFile. Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups. <rdar://problem/19716267> llvm-svn: 228261
* Fix it so we always get major, minor and update from the version in ↵Greg Clayton2015-02-041-12/+4
| | | | | | | | ObjectFileMachO::GetMinimumOSVersion(...) and ObjectFileMachO::GetSDKVersion(...). <rdar://problem/19697053> llvm-svn: 228092
* The lldb unwinder can now use the unwind information from the compact-unwind Jason Molenda2014-12-081-4/+17
| | | | | | | | | | | | | | | | | | section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
* Enable armv7 core file writing for Mach-O binaries. Jason Molenda2014-11-121-3/+4
| | | | | | | The problems with the dyld all image infos struct seems to be specific to arm64. llvm-svn: 221760
* Sketch out the armv7 and arm64 core file writing support inJason Molenda2014-11-121-7/+169
| | | | | | | | | | | | | | | ObjectFileMachO. It's close but we seem to be missing some of the memory region segments - not exactly sure how that's happening. The register context writing into the LC_THREAD load commands is working correctly though. Slightly reordered the arm64 definitions in ArchSpec.cpp so when we look for an arm64 core file definiton we're getting a cpu subtype of CPU_ANY which we can't put in the mach header of a core file. Make the first definition we find by linear search have the currently correct '1' cpu subtype. llvm-svn: 221743
* Add support for 32-bit core file dumping. Add support for i386 process core ↵Jason Molenda2014-11-111-20/+120
| | | | | | file dumping. llvm-svn: 221683
* Remove unused variable.Jason Molenda2014-10-161-3/+1
| | | | | | clang static analyzer fixit. llvm-svn: 219904
* Fixed an issue where the last N load commands in the mach-o core file would ↵Greg Clayton2014-09-161-0/+1
| | | | | | | | | | not be read in where N was the number of LC_THREAD load commands. I now properly increment the ncmds for each LC_THREAD and now core files are saved correctly. <rdar://problem/18312703> llvm-svn: 217905
* Fix up lldb build for llvm r217172.Todd Fiala2014-09-041-3/+3
| | | | | | Changes reference to 4th element in version_min_command from reserved to sdk. llvm-svn: 217185
* When adding a dSYM to an existing ObjectFile, we can have a situationJason Molenda2014-08-221-0/+12
| | | | | | | | | | | | | | | | | | with binaries in the dyld shared cache (esp on iOS) where the file address for the executable binary (maybe from memory, maybe from an expanded copy of the dyld shared cache) is different from the file address in the dSYM. In that case, ObjectFileMachO replaces the file addresses from the original binary with the dSYM file addresses (usually 0-based) -- lldb doesn't have a notion of two file addresses for a given module so they need to agree. There was a cache of file addresses over in the Symtab so I added a method to the Module and the objects within to clear any file address caches if they exist, and added an implementation in the Symtab module to do that. <rdar://problem/16929569> llvm-svn: 216258
* When constructing an ArchSpec from a MachO cpu type and subtype, don't set ↵Greg Clayton2014-07-291-2/+6
| | | | | | | | the OS for x86_64 and x86 in case the binary ends up being for macosx or ios. <rdar://problem/17819272> llvm-svn: 214188
* ObjectFileMachO: Silence signed/unsigned comparison warningDavid Majnemer2014-07-241-2/+1
| | | | | | | | | | | | | | | | | | | | File::SeekFromStart returns an off_t representing the position of the file after seeking. This return value is always going to be one of two values: the input or -1 in the case of failure. ObjectFileMachO compares an expression of type off_t from the return of File::SeekFromStart(segment.fileoff) and compares it for equality with segment.fileoff. The type of segment_command_64::fileoff is unsigned while off_t is signed, comparing them emits a diagnostic under GCC. Instead, we can just compare SeekFromSTart with -1 to see if we successfully seeked. Differential Revision: http://reviews.llvm.org/D4634 llvm-svn: 213822
* Plugins: silence a few more signed comparision warningsSaleem Abdulrasool2014-07-231-1/+2
| | | | | | Address a few signed-compare warnings that were triggered on GCC 4.8.2. llvm-svn: 213716
* Target: silence a GCC warningSaleem Abdulrasool2014-07-231-1/+3
| | | | | | | | | GCC emits a warning: warning: enumeral and non-enumeral type in conditional expression [enabled by default] which does not seem to have a flag to control it. Simply add an explicit cast for the boolean value. llvm-svn: 213715
* Use PRIx64.Joerg Sonnenberger2014-07-181-1/+1
| | | | llvm-svn: 213366
* Fixed the objective C symbol parsing in ObjectFileMachO.Greg Clayton2014-07-171-6/+0
| | | | | | | | | | | | | This fixes all of the hidden ivar test cases and any case where we try to find the full definition of an objective C class. This also means hidden ivars show up again. <rdar://problem/15458957> llvm.org/pr20270 llvm.org/pr20269 llvm.org/pr20272 llvm-svn: 213328
* __arm64__ and __aarch64__ #ifdef adjustmentsTodd Fiala2014-07-091-4/+4
| | | | | | | | Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
* Fix typos.Bruce Mitchener2014-07-011-13/+13
| | | | llvm-svn: 212132
* Patch from Keno Fischer to enable JITLoaderGDB with mach-o file support.Greg Clayton2014-06-241-1/+4
| | | | | | The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded. llvm-svn: 211638
* Correctly classify code sections as code sections by using the ↵Greg Clayton2014-06-161-113/+149
| | | | | | | | | | S_ATTR_PURE_INSTRUCTIONS and S_ATTR_SOME_INSTRUCTIONS section flags. Also correctly set the symbol type of symbols for S_REGULAR and other section types. <rdar://problem/16896734> llvm-svn: 211073
* Remove unused variablesSaleem Abdulrasool2014-06-131-1/+1
| | | | | | | | Address the 'variable set but not used' warning from GCC. In some cases a few additional calls were removed where there should be no visible side effects of the calls (i.e. should not effect any cached state). llvm-svn: 210879
* Added the ability to save core files:Greg Clayton2014-06-132-1/+419
| | | | | | | | | | | (lldb) file /bin/ls (lldb) b malloc (lldb) run (lldb) process save-core /tmp/ls.core Each ObjectFile plug-in now has the option to save core files by registering a new static callback. llvm-svn: 210864
* iOS simulator cleanup to make sure we use "*-apple-ios" for iOS simulator ↵Greg Clayton2014-05-292-47/+102
| | | | | | | | | | | | | | | | | | apps and binaries. Changes include: - ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands - ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK). - Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo - PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using: (lldb) platform select ios-simulator (lldb) platform process list - debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables - GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly <rdar://problem/17060217> llvm-svn: 209852
* ReExported symbols can point to a library that doesn't actuallyJim Ingham2014-05-212-0/+12
| | | | | | | | | contain the symbol, but just reexports wholesale from another library. Handle this case. <rdar://problem/16977589> llvm-svn: 209270
* When increasing the amount of a file read, read the total of the Mach-O headerJason Molenda2014-04-221-2/+3
| | | | | | | | plus the size of the load commands in case the LC_UUID load command comes near the end of the file. <rdar://problem/16599318> llvm-svn: 206865
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-5/+9
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Workaround for collision between enum members in LLVM's MachO.h and system ↵Jim Ingham2014-04-022-5/+6
| | | | | | | | | | headers on Mac OS X (in particular mach/machine.h). <rdar://problem/16494607> llvm-svn: 205480
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+1
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* lldb arm64 import.Jason Molenda2014-03-291-6/+151
| | | | | | | | | | | | | | | | These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
* Verify we have a correct ELF or Mach core file before we return a valid ↵Greg Clayton2014-03-071-3/+2
| | | | | | instace of ProcessElfCore or ProcessMachCore respectively. llvm-svn: 203274
* Modified ObjectFile::SetLoadAddress() to now be:Greg Clayton2014-02-072-22/+85
| | | | | | | | | | | | | | ObjectFile::SetLoadAddress (Target &target, lldb::addr_t value, bool value_is_offset); Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides. Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing. Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file. llvm-svn: 201003
OpenPOWER on IntegriCloud