summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
Commit message (Collapse)AuthorAgeFilesLines
* ObjectFileMachO: use early return to remove one nesting level from ↵Pavel Labath2018-03-031-532/+513
| | | | | | | | CreateSections() NFCI llvm-svn: 326667
* lldb running on an ios device is using the _dyld_get_all_image_infos()Jason Molenda2018-02-071-0/+21
| | | | | | | | | SPI call to to find its own shared cache's UUID. On newer sytems we need to use the a new SPI which will return the UUID directly. <rdar://problem/36625871> llvm-svn: 324437
* Compile the LLDB tests out-of-tree.Adrian Prantl2018-01-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch is the result of a discussion on lldb-dev, see http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for background. For each test (should be eventually: each test configuration) a separate build directory is created and we execute make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test In order to make this work all LLDB tests need to be updated to find the executable in the test build directory, since CWD still points at the test's source directory, which is a requirement for unittest2. Although we have done extensive testing, I'm expecting that this first attempt will break a few bots. Please DO NOT HESITATE TO REVERT this patch in order to get the bots green again. We will likely have to iterate on this some more. Differential Revision: https://reviews.llvm.org/D42281 llvm-svn: 323803
* Make sure DataBufferLLVM contents are writablePavel Labath2017-12-211-23/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that ability before, but with the introduction of DataBufferLLVM, we have lost it, as the underlying llvm class (MemoryBuffer) only supports read-only mappings. This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer class as a back-end, as this one guarantees to return a writable buffer. This removes the need for the "Private" flag to the DataBufferLLVM creation functions, as it was really used to mean "writable". The LLVM function also does not have the NullTerminate flag, so I've modified our clients to not require this feature and removed that flag as well. Reviewers: zturner, clayborg, jingham Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D40079 llvm-svn: 321255
* Fix alignment of arm64 fpu register context structureJason Molenda2017-11-161-1/+1
| | | | | | | | | | so it has the same padding as the kernel's definition which is written in terms of uint128_t. Original patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318357
* Roll back r318260 because it is causing the windows bot toJason Molenda2017-11-151-1/+1
| | | | | | | | | | break. The alignas(__uint128_t) is not recognized with MSVC it looks like. Zachary, is there a similar type on windows? I suppose I can go with alignas(16) here but I'd prefer to specify the type alignment that I want & let the ABI dictate how much padding is required. llvm-svn: 318262
* Two small fixes to handle arm64 fpu register contexts in Jason Molenda2017-11-151-1/+1
| | | | | | | | | a Mach-O file load command correctly, patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318260
* Move ArchSpec to the Utility modulePavel Labath2017-11-131-1/+1
| | | | | | | | | | | | | The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
* Add support for the DWP debug info formatTamas Berghammer2017-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: The DWP (DWARF package) format is used to pack multiple dwo files generated by split-dwarf into a single ELF file to make distributing them easier. It is part of the DWARFv5 spec and can be generated by dwp or llvm-dwp from a set of dwo files. Caviats: * Only the new version of the dwp format is supported (v2 in GNU numbering schema and v5 in the DWARF spec). The old version (v1) is already deprecated but binutils 2.24 still generates that one. * Combining DWP files with module debugging is not yet supported. Subscribers: emaste, mgorny, aprantl Differential Revision: https://reviews.llvm.org/D36062 llvm-svn: 311775
* Move Timer and TraceOptions from Core to UtilityPavel Labath2017-06-291-1/+1
| | | | | | | | | | | | | | Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
* [DWARFCallFrameInfo] Add Type enum to differentiate eh/debug_frame sectionsPavel Labath2017-06-281-1/+1
| | | | | | | | | | | | | | | | | Summary: instead of using a boolean to differentiate between the two section types, use an enum to make the intent clearer. I also remove the RegisterKind argument from the constructor, as this can be deduced from the Type argument. Reviewers: clayborg, jasonmolenda Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D34681 llvm-svn: 306521
* Remove an expensive lock from TimerPavel Labath2017-05-151-2/+2
| | | | | | | | | | | | | The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
* Rename Error -> Status.Zachary Turner2017-05-121-5/+5
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Don't use uuid_clear(), non-darwin platforms includeJason Molenda2017-04-131-1/+1
| | | | | | | Utility/UuidCompatibility.h which gets you a definiton of uuid_t but none of the functions that operate on it. llvm-svn: 300162
* Use two LC_NOTE load commands for identifying the main binary thatJason Molenda2017-04-121-5/+106
| | | | | | | | | | | | | | | | | lldb should use when given a corefile. This uses an LC_NOTE "main bin spec" or an LC_NOTE "kern ver str" if they are present in a Mach-O core file. Core files may have multiple different binaries -- different kernels, or a mix of user process and kernel binaries -- and it can be difficult for lldb to detect the correct one to use simply by looking at the pages of memory. These two new LC_NOTE load commands allow for the correct binary to be recorded unambiguously. <rdar://problem/20878266> llvm-svn: 300138
* iwyu fixes for lldbCore.Zachary Turner2017-04-061-0/+1
| | | | | | | | | | | | | | This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
* Some old mach-o core files have an LC_IDENT load command Jason Molenda2017-04-061-0/+31
| | | | | | | | and there's a string in there that can be helpful in locating the kernel binary. Use it. <rdar://problem/31444711> llvm-svn: 299612
* Move FileSpec from Host -> Utility.Zachary Turner2017-03-221-1/+1
| | | | llvm-svn: 298536
* Get ObjectFileMachO to handle @executable_pathJim Ingham2017-03-201-2/+25
| | | | | | | | | Only do this when we are debugging an executable, since we don't have a good way to trace from an ObjectFile back to its containing executable. Detecting pre-run libs before running is "best effort" in lldb, but this one is pretty easy. llvm-svn: 298290
* Remove FileSpec::ReadFileContents.Zachary Turner2017-03-061-9/+10
| | | | | | | | | | | | | | | | This functionality is subsumed by DataBufferLLVM, which is also more efficient since it will try to mmap. However, we don't yet support mmaping writable private sections, and in some cases we were using ReadFileContents and then modifying the buffer. To address that I've added a flag to the DataBufferLLVM methods that allow you to map privately, which disables the mmaping path entirely. Eventually we should teach DataBufferLLVM to use mmap with writable private, but that is orthogonal to this effort. Differential Revision: https://reviews.llvm.org/D30622 llvm-svn: 297095
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-12/+17
| | | | llvm-svn: 296943
* Move UUID from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296941
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Delete DataBufferMemoryMap.Zachary Turner2017-02-241-36/+48
| | | | | | | | | | | | | | | After a series of patches on the LLVM side to get the mmaping code up to compatibility with LLDB's needs, it is now ready to go, which means LLDB's custom mmapping code is redundant. So this patch deletes it all and uses LLVM's code instead. In the future, we could take this one step further and delete even the lldb DataBuffer base class and rely entirely on LLVM's facilities, but this is a job for another day. Differential Revision: https://reviews.llvm.org/D30054 llvm-svn: 296159
* Move classes from Core -> Utility.Zachary Turner2017-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-1/+2
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* [lldb] Fix -Waggressive-loop-optimizations warningVedant Kumar2016-11-071-1/+5
| | | | | | | | | We shouldn't access past the end of an array, even if we think that the layout of the struct containing the array is always what we expect. The compiler is free to optimize away the stores as undefined behavior, and in fact, GCC 6.2.1 claims it will do exactly this. llvm-svn: 286093
* Improve ".." handling in FileSpec normalizationPavel Labath2016-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: .. handling for windows path was completely broken because the function was expecting \ as path separators, but we were passing it normalized file paths, where these have been replaced by forward slashes. Apart from this, the function was incorrect for posix paths as well in some corner cases, as well as being generally hard to follow. The corner cases were: - /../bar -> should be same as /bar - /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually existing, but since we're doing it in an abstract way, I think the transformation is reasonable) I rewrite the function to fix these corner cases and handle windows paths more correctly. The function should now handle the posix paths (modulo symlinks, but we cannot really do anything about that without a real filesystem). For windows paths, there are a couple of corner cases left, mostly to do with drive letter handling, which cannot be fixed until the rest of the class understands drive letters better. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26081 llvm-svn: 285593
* Fix about a dozen compile warningsIlia K2016-09-121-9/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: It fixes the following compile warnings: 1. '0' flag ignored with precision and ‘%d’ gnu_printf format 2. enumeral and non-enumeral type in conditional expression 3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ... 4. enumeration value ‘...’ not handled in switch 5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers 6. extra ‘;’ 7. comparison between signed and unsigned integer expressions 8. variable ‘register_operand’ set but not used 9. control reaches end of non-void function Reviewers: jingham, emaste, zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24331 llvm-svn: 281191
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-5604/+5582
| | | | | | | | | | | | | | | | | | | | | | | *** 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-181-10/+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-041-2/+24
| | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud