summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/Mach-O
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-062-5827/+5755
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* If the user has specified target.memory-module-load-level 'minimal'Jason Molenda2016-08-251-3/+5
| | | | | | | | | | | and we couldn't find a dyld binary on the debug system, override that setting and read dyld out of memory - we need to put an internal breakpoint on dyld to register binaries being loaded or unloaded; the debugger won't work right without dyld symbols. <rdar://problem/27857025> llvm-svn: 279704
* Delete Host/windows/win32.hZachary Turner2016-08-091-1/+1
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Move the code which knows how to get information about the sharedJason Molenda2016-07-291-63/+7
| | | | | | | | | | cache from ObjectFileMachO (very wrong place) to the DynamicLoader plugins (better place). Not much change to the code itself, although the old ObjectFileMachO method would try both the new dyld SPI and reading the dyld_all_image_infos structure. In the new methods, I've separated those into the appropriate DynamicLoader plugins. llvm-svn: 277088
* Add support to get the shared cache information from the newJason Molenda2016-07-221-0/+27
| | | | | | | | | | | | | debugserver jGetSharedCacheInfo packet instead of reading the dyld internal data structures directly. This code is (currently) only used for ios native lldb's - I should really move this ObjectFileMachO::GetProcessSharedCacheUUID method somewhere else, it makes less and less sense being in the file reader. <rdar://problem/25251243> llvm-svn: 276369
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-231-3/+3
| | | | | | | | for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll need to look at this more closely before re-committing. (passed OK on macOS ;) llvm-svn: 273531
* Do some minor renames of "Mac OS X" to "macOS".Jason Molenda2016-06-231-3/+3
| | | | | | | | | There's uses of "macosx" that will be more tricky to change, like in triples (e.g. "x86_64-apple-macosx10.11") - for now I'm just updating source comments and strings printed for humans. llvm-svn: 273524
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-091-1/+7
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* Small further refinement to the check in ObjectFileMachO::ParseSymtabJason Molenda2016-05-261-7/+9
| | | | | | | | | | | | | | | | | which looks for binaries missing an LC_FUNCTION_STARTS section because it was stripped/not emitted. If we see a normal user process binary (executable, dylib, framework, bundle) without LC_FUNCTION_STARTS, that is unusual and we should disallow instruction emulation because that binary has likely been stripped a lot. If this is a non-user process binary -- a kernel, a standalone bare-board binary, a kernel extension (kext) -- and there is no LC_FUNCTION_STARTS, we should not assume anything about the binary and allow instruction emulation as we would normally do. <rdar://problem/26453952> llvm-svn: 270818
* Ach, editing too many files at once. Make this file compile again.Jason Molenda2016-05-241-1/+1
| | | | llvm-svn: 270620
* In r268475 I made a change to ObjectFileMachO so that if it isJason Molenda2016-05-241-1/+4
| | | | | | | | | | | | | | | | missing an LC_FUNCTION_STARTS section, we assume it has been aggressively stripped (it is *very* unusual for anyone to strip LC_FUNCTION_STARTS) so we disable assembly instruction unwind plan creation. Kernel extensions (kexts) don't have LC_FUNCTION_STARTS, but we almost always have good symbol bounds just with the linker symbols. So add an exception to allow assembly instruction unwind plan creation for kexts even though they lack LC_FUNCTION_STARTS. <rdar://problem/26453952> llvm-svn: 270618
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-1/+1
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-182-11/+10
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Add a way for an ObjectFile to indicate that assembly emulationJason Molenda2016-05-042-2/+28
| | | | | | | | | | | | | | | | | | | | | should not be used for this module -- for use when an ObjectFile knows that it does not have meaningful or accurate function start addresses. More commonly, it is not clear that function start addresses are missing in a module. There are certain cases on Mac OS X where we can tell that a Mach-O binary has been stripped of this essential information, and the unwinder can end up emulating many megabytes of instructions for a single "function" in the binary. When a Mach-O binary is missing both an LC_FUNCTION_STARTS load command (very unusual) and an eh_frame section, then we will assume it has also been stripped of symbols and that instruction emulation will not be useful on this module. <rdar://problem/25988067> llvm-svn: 268475
* Update the on-device arm specific code to match the API changesJason Molenda2016-03-011-5/+5
| | | | | | | that happened in other parts of this file so it builds cleanly for arm again. llvm-svn: 262300
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* Add support for handling absolute symbols in ELFTamas Berghammer2016-02-251-0/+1
| | | | | | | | | | | | | | | Most address represented in lldb as section plus offset and handling of absolute addresses is problematic in several location because of lack of necessary information (e.g. Target) or because of performance issues. This CL change the way ObjectFileELF handle the absolute symbols with creating a pseudo section for each symbol. With this change all existing code designed to work with addresses in the form of section plus offset will work with absolute symbols as well. Differential revision: http://reviews.llvm.org/D17450 llvm-svn: 261859
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-181-8/+1
| | | | | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Revert "Improve the handling of missing elf symtab and missing symbol sizes"Tamas Berghammer2016-02-101-1/+8
| | | | | | | | This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce. The commit caused several test failure on the OSX build bot. llvm-svn: 260377
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-101-8/+1
| | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 260369
* Revert "[NFC] Cleanup RangeMap.h"Todd Fiala2016-02-021-175/+0
| | | | | | | This reverts commit r259538. Caused 92 test failures on the OS X testbot. llvm-svn: 259556
* [NFC] Cleanup RangeMap.hTamas Berghammer2016-02-021-0/+175
| | | | | | | | | | | | | | | | | The file contained very similar 4 implementation of the same data structure with a lot of duplicated code and some minor API differences. This CL refactor the class to eliminate the duplicated codes and to unify the APIs. RangeMap.h also contained a class called AddressDataArray what have very little added functionality over an std::vector and used only by ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't belongs into RangeMap.h and shouldn't be used in new places anyway because of the little added functionality. Differential revision: http://reviews.llvm.org/D16769 llvm-svn: 259538
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,Jason Molenda2016-01-211-3/+16
| | | | | | | | | | | | | | | | | | | | | | set the triple's "vendor" field to Apple. We don't want to assume a vendor of Apple for all Mach-O files - this breaks x86_64 EFI debugging where they put non-Apple binaries in a Mach-O format for ease of handling. But on armv7, Apple's ABI always uses r7 as the frame pointer register; if we don't set the Vendor field to Apple, we can pick up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which breaks backtracing altogether. Greg is reluctant for us to make any assumptions about the Vendor here, but we'll see how this shakes out. It's such a big problem on armv7 if we don't know this is using the Apple ABI that it's worth trying this approach. <rdar://problem/22137561> llvm-svn: 258387
* Some 32-bit arm corefiles on darwin may have their general purposeJason Molenda2016-01-201-1/+2
| | | | | | | | | | register set indicated by ARM_THREAD_STATE32 (value 9) instead of the old ARM_THREAD_STATE (value 1); this patch changes lldb to accept either register set flavor code. <rdar://problem/24246257> llvm-svn: 258289
* Read macro info from .debug_macro section and use it for expression evaluation.Siva Chandra2015-12-161-0/+1
| | | | | | | | | | | | | | | | | Summary: DWARF 5 proposes a reinvented .debug_macro section. This change follows that spec. Currently, only GCC produces the .debug_macro section and hence the added test is annottated with expectedFailureClang. Reviewers: spyffe, clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15437 llvm-svn: 255729
* Add support for tvos and watchos to ObjectFileMachO.Jason Molenda2015-11-102-147/+217
| | | | | | | | Add support for the new dyld shared cache format on ios etc devices. Small changes for classifying ObjC metadata symbols. llvm-svn: 252588
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-071-10/+10
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* Make sure we don't over specify an architecture when we connect to KDP and ↵Greg Clayton2015-10-281-11/+16
| | | | | | | | use the CPU type and subtype to fill out an architecture. We do this by letting the vendor be an unspecified unknown, or any. We also grab the target architecture, get the KDP host arch, and then merge the two before putting it back into the target. Also change MH_PRELOAD to be use "unspecified unknown" (any) for the OS and vendor since these mach files can really be anything. llvm-svn: 251579
* Don't crash when opening a fuzzed mach-o file that has bad dyld trie data.Greg Clayton2015-10-281-9/+17
| | | | | | <rdar://problem/21991784> llvm-svn: 251555
* Fix Clang-tidy modernize-use-override warnings in ↵Eugene Zelenko2015-10-232-173/+150
| | | | | | source/Plugins/ObjectContainer and ObjectFile; other minor fixes. llvm-svn: 251119
* Add support for .ARM.exidx unwind informationTamas Berghammer2015-09-301-0/+2
| | | | | | | | | .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-0/+4
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Add support for DW_FORM_GNU_[addr,str]_indexTamas Berghammer2015-08-251-0/+2
| | | | | | | | | These are 2 new value currently in experimental status used when split debug info is enabled. Differential revision: http://reviews.llvm.org/D12238 llvm-svn: 245931
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-1/+0
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* 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
OpenPOWER on IntegriCloud