summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert logging addition to SBCompileUnit::GetNumLineEntries,Jason Molenda2019-03-051-6/+1
| | | | | | causing lldb-mi testsuite failures? llvm-svn: 355449
* Add logging to SBCompileUnit::GetNumLineEntries.Jason Molenda2019-03-051-1/+6
| | | | llvm-svn: 355435
* [DataFormatters] Fix regression in libc++ std::atomic formatter caused by ↵Shafik Yaghmour2019-03-052-6/+64
| | | | | | | | https://reviews.llvm.org/D56913 rdar://problem/48568543 llvm-svn: 355422
* Revert "Fix embedded Python initialization according to changes in version 3.7"Tatyana Krasnukha2019-03-051-13/+1
| | | | | | Testsuite hangs on Windows likely due to these changes. llvm-svn: 355406
* Adds property to force enabling of GDB JIT loader for MacOSYury Delendik2019-03-051-12/+37
| | | | | | | | | | | | | | | | | Summary: Based on https://gist.github.com/thlorenz/30bf0a3f67b1d97b2945#patching-and-rebuilding The functionality was disabled at https://github.com/llvm/llvm-project/commit/521c2278abb16f0148cef1bd061cadb01ef43192 Reviewers: jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D57689 llvm-svn: 355402
* One more UserIDResolver fixPavel Labath2019-03-051-1/+1
| | | | | | | | | | | | | | | | | The intention in r355323 has been to implement a no-op resolver in the HostInfoBase class, which will then be shadowed a an implementation in the HostInfoPosix class. However, I add the shadowing declaration in HostInfoPosix.h, and instead had implemented the HostInfoBase function in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and a subsequent implementation of a no-op resolver in HostInfoWindows (r355329). Since now there is no point on having a no-op resolver in the base class, I just remove the base declaration altogether, and have HostInfoPosix implement the (newly-declared) HostInfoPosix version of that function. llvm-svn: 355398
* [lldb] Fix linux host build after r355342Alexander Kornienko2019-03-051-0/+1
| | | | llvm-svn: 355392
* Fix embedded Python initialization according to changes in version 3.7Tatyana Krasnukha2019-03-051-1/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D58833 llvm-svn: 355388
* [Expression] Remove unused parameter from EvaluateAlex Langford2019-03-053-8/+6
| | | | llvm-svn: 355375
* [Host] Fix the build (and the modules build).Davide Italiano2019-03-051-0/+1
| | | | | | | -> Add a missing include to find the base class. -> Add a missing out-of-line declaration for a member function. llvm-svn: 355353
* Revert "[DataFormatters] Fix regression in libc++ std::atomic formatter ↵Shafik Yaghmour2019-03-051-27/+5
| | | | | | | | caused by https://reviews.llvm.org/D56913" This reverts commit r355351. llvm-svn: 355352
* [DataFormatters] Fix regression in libc++ std::atomic formatter caused by ↵Shafik Yaghmour2019-03-051-5/+27
| | | | | | | | https://reviews.llvm.org/D56913 rdar://problem/48568543 llvm-svn: 355351
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-0421-327/+358
| | | | | | | | | | | | | | | | | | | | | There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist. To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being. After this there is only 2 remaining references to Target from Host, which I'll address in a followup. Differential Revision: https://reviews.llvm.org/D58842 llvm-svn: 355342
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
* Fix Windows build after UserIDResolver patch.Zachary Turner2019-03-041-0/+20
| | | | | | | | | That patch added a function to HostInfo that returns an instance of UserIDResolver, but this function was unimplemented on Windows, leading to linker errors. For now, just return a dummy implementation that doesn't resolve user ids to get the build green. llvm-svn: 355329
* Refactor user/group name resolving codePavel Labath2019-03-0411-167/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This creates an abstract base class called "UserIDResolver", which can be implemented to provide user/group ID resolution capabilities for various objects. Posix host implement a PosixUserIDResolver, which does that using posix apis (getpwuid and friends). PlatformGDBRemote forwards queries over the gdb-remote link, etc. ProcessInstanceInfo class is refactored to make use of this interface instead of taking a platform pointer as an argument. The base resolver class already implements caching and thread-safety, so implementations don't have to worry about that. The main motivating factor for this was to remove external dependencies from the ProcessInstanceInfo class (so it can be put next to ProcessLaunchInfo and friends), but it has other benefits too: - ability to test the user name caching code - ability to test ProcessInstanceInfo dumping code - consistent interface for user/group resolution between Platform and Host classes. Reviewers: zturner, clayborg, jingham Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58167 llvm-svn: 355323
* [lldb] [Process/gdb-remote] Use '127.0.0.1' in ConnectLocally()Michal Gorny2019-03-031-1/+1
| | | | | | | | | | | | | | | | Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function as this is the specific address the server is bound to. Using 'localhost' may involve trying IPv6 first which may accidentally be used by another service. While technically it might be interesting to support IPv6 here, it would need to be supported properly, with the connection copying family and address from the listening socket, and possibly without relying on existence of 'localhost' at all. Differential Revision: https://reviews.llvm.org/D58883 llvm-svn: 355285
* Fix gcc build for r355249Pavel Labath2019-03-021-1/+1
| | | | | | | automatic move should not fire when returning type T in a function with result type Expected<T>. Some compilers seem to allow that nonetheless. llvm-svn: 355270
* [Reproducers] Capture and replay interpreter commands.Jonas Devlieghere2019-03-028-31/+143
| | | | | | | | | | | | | | | | | This patch adds the necessary logic to capture and replay commands entered into the command interpreter. A DataRecorder shadows the input and writes its data to a know file. During replay this file is used as the command interpreter's input. It's possible to the command interpreter more than once, with a different input source. We support this scenario by using multiple buffers. The synchronization for this takes place at the SB layer, where we create a new recorder every time the debugger input is changed. During replay we use the corresponding buffer as input. Differential revision: https://reviews.llvm.org/D58564 llvm-svn: 355249
* Delete commented-out code.Adrian Prantl2019-03-011-6/+0
| | | | llvm-svn: 355238
* Resubmit r354706 with a fix for process launch.Jim Ingham2019-03-013-41/+89
| | | | | | | | | | | | | | | When the debugger is run in sync mode, you need to be able to tell whether a hijacked resume is for some special purpose (like waiting for the SIGSTOP on attach) or just to perform a synchronous resume. Target::Launch was doing that wrong, and that caused stop-hooks on process launch in source files to behave incorrectly. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58727 llvm-svn: 355213
* Increase timeout in Symbols::DownloadObjectAndSymbolFile Jason Molenda2019-03-011-1/+1
| | | | | | | | | | from 30 seconds to 120 seconds. We've seen cases where this symbol lookup can exceed 30 seconds for people working remotely. <rdar://problem/48460476> llvm-svn: 355169
* [CMake] Make liblldb depend on clang-headersAlex Langford2019-02-281-0/+4
| | | | | | | | | | | Summary: The clang headers are useful when dealing with clang modules. There is also a way to get to the clang headers from the SB API so it would be nice if they were also available when we just build lldb. Differential Revision: https://reviews.llvm.org/D58793 llvm-svn: 355149
* Improve process launch comments for WindowsAdrian McCarthy2019-02-281-3/+7
| | | | | | | | | | | | | The existing comment about over-allocating the command line was incorrect. The contents of the command line may be changed, but it's not necessary to over allocate. The changes will be limited to the existing contents of the string (e.g., by replacing spaces with L'\0' to tokenize the command line). Also added a comment explaining a possible cause of failure to save the next programmer some time when they try to debug a 64-bit process from a 32-bit LLDB. llvm-svn: 355121
* [Reprodicuers] Check initializationJonas Devlieghere2019-02-281-0/+4
| | | | | | | If the reproducer is not initialzied, the call to ::Instance() will result in an assertion. llvm-svn: 355055
* Remove unnecessary demangling operation (NFC)Adrian Prantl2019-02-271-7/+5
| | | | | | | | | | | | This extra call to the demangler doesn't affect the performance of C++ because the result is being cached anyway; but I'm working on a patch to the Swift branch that uses extra contextual information to provide a more accurate demangling result. In that case this call would be extra and unnecessary work. Differential Revision: https://reviews.llvm.org/D58720 llvm-svn: 355042
* Remove dependency from Host -> Core.Zachary Turner2019-02-271-1/+0
| | | | | | | I wasn't actually trying to eliminate this one, but looks like it happened as a side effect of moving Symbols out of Host. llvm-svn: 355037
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-2713-30/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032
* Pass arguments correctly to the objc object checker on arm64Jim Ingham2019-02-271-2/+9
| | | | | | | | | | | | | | | | | Traditionally objc had two entry points, objc_msgSend for scalar return methods, and objc_msgSend_stret for struct return convention methods. But on arm64 the second was not needed (since arm64 doesn't use an argument register for the struct return pointer) so it was removed. The code that dispatches to the objc object checker when it sees some flavor of objc_msgSend was not aware of this change so was sending the wrong arguments to the checker. <rdar://problem/48315890> Differential Revision: https://reviews.llvm.org/D58699 llvm-svn: 355026
* [Reproducer] Make 'reproducer generate' a NOOP during replay.Jonas Devlieghere2019-02-271-0/+5
| | | | | | | Instead of filtering out the 'reproducer generate' command during replay, just make the operation a NOOP. llvm-svn: 355009
* [Reproducers] Add more logging to reproducer instrumentationJonas Devlieghere2019-02-271-4/+29
| | | | | | | | | | | Debugging issues with instrumentation capture and replay can be particularly tricky, especially because part of the process takes places even before the debugger is initialized. This patch adds more logging capabilities to these classes, hidden behind a macro define. Differential revision: https://reviews.llvm.org/D58566 llvm-svn: 355002
* [Utility] Fix ArchSpec.MergeFrom to correctly merge environmentsAlex Langford2019-02-271-3/+2
| | | | | | | | | | | | | | | | Summary: This behavior was originally added in rL252264 (git commit 76a7f365da) in order to be extra careful with handling platforms like watchos and tvos. However, as far as triples go, those two (and others) are treated as OSes and not environments, so that should not really apply here. Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs. Because android is specified as an environment and not an OS, not propogating the environment can lead to modules and targets being misidentified. Differential Revision: https://reviews.llvm.org/D58664 llvm-svn: 354938
* [Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpecAlex Langford2019-02-262-6/+5
| | | | | | | | | | | | | | Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
* Fix error handling in Options::ParseTatyana Krasnukha2019-02-261-2/+3
| | | | | | | Moved `if (error.Fail())` to correct place to catch all faulty cases such as "unknown or ambiguous option" which was ignored before. llvm-svn: 354883
* Revert r354706 - lit touched my thighJim Ingham2019-02-233-69/+20
| | | | llvm-svn: 354711
* Make sure that stop-hooks run asynchronously.Jim Ingham2019-02-233-20/+69
| | | | | | | | | | | | | | They aren't designed to nest recursively, so this will prevent that. Also add a --auto-continue flag, putting "continue" in the stop hook makes the stop hooks fight one another in multi-threaded programs. Also allow more than one -o options so you can make more complex stop hooks w/o having to go into the editor. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58394 llvm-svn: 354706
* When deserializing breakpoints some options may not be present.Jim Ingham2019-02-221-15/+10
| | | | | | | | | | | The deserializer was not handling this case. For now we just accept the absent option, and set it to the breakpoint default. This will be more important if/when I figure out how to serialize the options set on breakpont locations. <rdar://problem/48322664> llvm-svn: 354702
* Avoid two-stage initialization of MinidumpParserPavel Labath2019-02-224-147/+126
| | | | | | | | | remove the Initialize function, move the things that can fail into the static factory function. The factory function now returns Expected<Parser> instead of Optional<Parser> so that it can give a reason why creation failed. llvm-svn: 354668
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-219-77/+46
| | | | | | | | | | | | | | | | As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
* Merge target triple into module triple when constructing module from memoryAlex Langford2019-02-201-0/+4
| | | | | | | | | | | | | | | | | | | Summary: While debugging an android process remotely from a windows machine, I noticed that the modules constructed from an object file in memory only had information about the architecture. Without knowledge of the OS or environment, expression evaluation sometimes leads to incorrectly generated code or a debugger crash. While we cannot know for certain what triple a module constructed from an in-memory object file will have, we can use the triple from the target to try and fill in the missing details. Reviewers: clayborg, zturner, JDevlieghere, compnerd, aprantl, labath Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58405 llvm-svn: 354526
* [lldb] [ObjectFile/ELF] Fix recognizing NetBSD imagesMichal Gorny2019-02-201-12/+29
| | | | | | | | | | | | | | | | | | | | | Split the recognition into NetBSD executables & shared libraries and core(5) files. Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged in the same way as regular NetBSD executables. Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG, IDENT_DECSZ, IDENT_NAMESZ and PROCINFO. The new values detect correctly the NetBSD images. The patch has been originally written by Kamil Rytarowski. I've added tests and applied minor code changes per review. The work has been sponsored by the NetBSD Foundation. Differential Revision: https://reviews.llvm.org/D42870 llvm-svn: 354466
* Add Facebook Minidump directory streams and options to dump them.Greg Clayton2019-02-193-2/+162
| | | | | | | | Facebook creates minidump files that contain specific information about why things crash. Adding ways to dump these allows tools to be made that can auto download symbols based on the information that is contained in the minidump files. Differential Revision: https://reviews.llvm.org/D58398 llvm-svn: 354385
* Revert "minidump: Add ability to attach (breakpad) symbol files to ↵Pavel Labath2019-02-191-71/+43
| | | | | | | | | | | | | | | | | | placeholder modules" This reverts r354263, because it uncovered a problem in handling of the minidumps with conflicting UUIDs. If a minidump contains two files with the same UUID, we will not create to placeholder modules for them, but instead reuse the first one for the second instance. This creates a problem because these modules have their load address hardcoded in them (and I've added an assert to verify that). Technically this is not a problem with this patch, as the same issue existed in the previous implementation, but it did not have the assert which would diagnose that. Nonetheless, I am reverting this until I figure out what's the best course of action in this situation. llvm-svn: 354324
* [gui] Simplify SourceFileWindowDelegate::WindowDelegateDrawPavel Labath2019-02-191-5/+2
| | | | | | | | | instead of printf-ing into a buffer, and them using that buffer as a format string, simply use the appropriate indirect format string. This also fixes a -Wformat-truncation warning with gcc. llvm-svn: 354307
* [Reproducers] Make clang use lldb's VFS.Jonas Devlieghere2019-02-184-2/+11
| | | | | | | | | | In r353906 we hooked up clang and lldb's reproducer infrastructure to capture files used by clang. This patch adds the necessary logic to have clang reuse the files from lldb's reproducer during replay. Differential revision: https://reviews.llvm.org/D58309 llvm-svn: 354283
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-02-181-43/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r353677, which was reverted due to test failures on the windows bot. The issue there was that ObjectFilePECOFF vended its base address through the incorrect interface. SymbolFilePDB depended on that, which lead to assertion failures when SymbolFilePDB was attempting to use the placeholder object files as a base. This has been fixed in r354258 It also fixes one small problem in the original patch. The issue was that the Module class would attempt to overwrite the object file we created in CreateModuleFromObjectFile if the file corresponding to the placeholder object file happened to exist (but we have already disqualified it due to UUID mismatch. The fix is simple -- we set the m_did_load_objfile flag to properly record the fact that we have already created an object file for the module. The original commit message was: The reason this wasn't working was that ProcessMinidump was creating odd object-file-less modules, and SymbolFileBreakpad required the module to have an associated object file because it needed to get its base address. This fixes that by introducing a PlaceholderObjectFile to serve as a dummy object file. The general idea for this is taken from D55142, but I've reworked it a bit to avoid the need for the PlaceholderModule class. Now that we have an object file, our modules are sufficiently similar to regular modules that we can use the regular Module class almost out of the box -- the only thing I needed to tweak was the Module::CreateModuleFromObjectFile functon to set the module's FileSpec in addition to it's architecture. This wasn't needed for ObjectFileJIT (the other user of CreateModuleFromObjectFile), but it shouldn't hurt it either, and the change seems like a straightforward extension of this function. Reviewers: clayborg, lemo, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D57751 llvm-svn: 354263
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-184-3/+8
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Return better error message from GDBRemoteCommunication::ConnectLocallyPavel Labath2019-02-181-3/+4
| | | | llvm-svn: 354256
* Remove unused extern declaration as removed by D32167Jan Kratochvil2019-02-171-2/+0
| | | | llvm-svn: 354225
* Add PythonBoolean type to the PythonDataObjectsTatyana Krasnukha2019-02-162-0/+78
| | | | | | Differential Revision: https://reviews.llvm.org/D57817 llvm-svn: 354206
OpenPOWER on IntegriCloud