summaryrefslogtreecommitdiffstats
path: root/lldb/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a broken comment line. NFC.Hafiz Abid Qadeer2019-03-251-2/+1
| | | | | | Just checking that commit access is working after licensing changes. llvm-svn: 356876
* [lldb] Add missing EINTR handlingMichal Gorny2019-03-212-4/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D59606 llvm-svn: 356703
* Change the logging on ptrace(PT_KILL) in MachProcess::Kill to logJason Molenda2019-03-201-3/+5
| | | | | | | | if LOG_PROCESS is enabled or if there was an error making that call. <rdar://problem/49036508> llvm-svn: 356626
* [lldb-vscode] Fix dangling pointer in request_evaluate.Jorge Gorbe Moya2019-03-151-1/+4
| | | | | | | | | | SBError::GetCString() returns a pointer to a string owned by the SBError object. The code here was calling GetCString on a temporary and using the returned pointer after the temporary was destroyed. Differential Revision: https://reviews.llvm.org/D59400 llvm-svn: 356227
* [lldb-vscode] Don't try to launch an invalid program.Jorge Gorbe Moya2019-03-131-0/+1
| | | | | | | | | | | | | | | If an invalid program is specified, lldb-vscode will send back a response with "success" = false, but then will continue executing the rest of request_launch(), try to launch the program anyway and try to send another response (possibly using the `response` object after it was moved). This change adds a return statement so we stop executing the handler after producing the first failing response. Differential Revision: https://reviews.llvm.org/D59340 llvm-svn: 356110
* [Reproducers] Support capturing a reproducer without an explicit path.Jonas Devlieghere2019-03-122-19/+38
| | | | | | | | | | | | | | Tablegen doesn't support options that are both flags and take values as an argument. I noticed this when doing the tablegen rewrite, but forgot that that affected the reproducer --capture flag. This patch makes --capture a flag and adds --capture-path to specify a path for the reproducer. In reality I expect this to be mostly used for testing, but it could be useful nonetheless. Differential revision: https://reviews.llvm.org/D59238 llvm-svn: 355936
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-118-114/+114
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* [lldb-instr] Support LLDB_RECORD_DUMMYJonas Devlieghere2019-03-081-13/+29
| | | | | | | Extend lldb-instr to insert LLDB_RECORD_DUMMY macros for currently unsupported signatures (void and function pointers). llvm-svn: 355710
* [lldb-vscode] Fix warningJonas Devlieghere2019-03-081-2/+2
| | | | | | | | I changed the variable to an unsigned to get rid of a signed and unsigned compare without realizing the value could be negative. This fixes the assert instead. llvm-svn: 355708
* [lldb-vscode] Report an error if an invalid program is specified.Zachary Turner2019-03-081-5/+8
| | | | | | | | | | | | | | | Previously if an invalid program was specified, there was a bug which, when we attempted to launch the program, would report that the operation succeeded, causing LLDB to then hang while waiting indefinitely to receive some events from the process. After this patch, when an invalid program is specified, we immediately return to vs code with an error message that indicates that the program can not be found. Differential Revision: https://reviews.llvm.org/D59114 llvm-svn: 355656
* Make bytes_read an unsignedJonas Devlieghere2019-03-071-1/+1
| | | | llvm-svn: 355651
* Remove unused functionJonas Devlieghere2019-03-071-6/+0
| | | | llvm-svn: 355650
* [lldb-vscode] Support running in server mode on Windows.Zachary Turner2019-03-077-86/+278
| | | | | | | | | | | | | | | | Windows can't use standard i/o system calls such as read and write to work with sockets, it instead needs to use the specific send and recv calls. This complicates matters for the debug adapter, since it needs to be able to work in both server mode where it communicates over a socket, as well as non-server mode where it communicates via stdin and stdout. To abstract this out, I've introduced a class IOStream which hides all these details and exposes a read/write interface that does the right on each platform. Differential Revision: https://reviews.llvm.org/D59104 llvm-svn: 355637
* [lldb-vscode] Correctly propagate errors back to VS Code.Zachary Turner2019-03-061-12/+12
| | | | llvm-svn: 355557
* [debugserver] Fix IsUserReady thread filteringFrederic Riss2019-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In 2010 (r118866), filtering code was added to debugserver to avoid reporting threads that were "not ready to be displayed to the user". This code inspects the thread's state and discards threads marked 'uninterruptible'. Turns out, this state is pretty common and not only a characterisitic of 'user-readiness'. This filtering was tracked down as the source of the flakiness of TestQueues and TestConcurrent* with the symptom of missing threads. We discussed with the kernel team and there should be no need for us to filter the restult of task_threads(). Everything that is returned from there can be examined. So I went on and tried to remove the filtering completely. This produces other test failures, where we were reporting more theads than expected. Always threads that had been terminated, but weren't removed from the task bookkeeping structures yet. Those threads always had a PC of 0. This patch changes the heuristic to make the filtering a little less strict and only rejects threads that are 'uninteruptible' *and* have a PC of 0. This has proven to be solid in my testing. Reviewers: jasonmolenda, clayborg, jingham Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58912 llvm-svn: 355555
* Sanity check --max-gdbserver-portJan Kratochvil2019-03-061-3/+3
| | | | | | | | | | | | | | | | | | | | In mail [lldb-dev] Remote debugging a docker process https://lists.llvm.org/pipermail/lldb-dev/2019-March/014795.html user was confused by --min-gdbserver-port and --max-gdbserver-port options being ignored. I think there is even a bug that --max-gdbserver-port is upper exclusive limit (and not upper inclusive limit appropriate for max). At least this patch should catch such mistake by an error message. The question is whether --max-gdbserver-port should not be changed to really be max and not max+1 but that would break backward compatibility. Now the mail example does produce: error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port (5001) Differential Revision: https://reviews.llvm.org/D58962 llvm-svn: 355554
* [Reproducers] Enable replay from SBRepro.Jonas Devlieghere2019-03-061-1/+1
| | | | | | | | | Now that the LLDB instrumentation macros are in place, we should use that to test reproducer replay. Differential revision: https://reviews.llvm.org/D58565 llvm-svn: 355470
* Update com.apple.diagnosticd.diagnostic entitlementJason Molenda2019-03-014-4/+4
| | | | | | | | name to the newer com.apple.private.logging.diagnostic. <rdar://problem/47183116> llvm-svn: 355170
* [lldb-mi] Return source line number in proper formatTatyana Krasnukha2019-02-251-1/+1
| | | | | | | | | Line number is a decimal number and is printed as such, however for some reason it was prefixed with '0x', thus turning printed value invalid. Patch by Anton Kolesov <Anton.Kolesov@synopsys.com> llvm-svn: 354804
* [lldb-mi] Fix conversion warning for 64-bit buildTatyana Krasnukha2019-02-251-1/+1
| | | | llvm-svn: 354803
* [lldb-mi] Check raw pointers before passing them to std::string ctor/assignmentTatyana Krasnukha2019-02-258-23/+31
| | | | | | Differential Revision: https://reviews.llvm.org/D55653 llvm-svn: 354798
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-217-18/+21
| | | | | | | | | | | | | | | | 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
* [lldb-instr] Group RECORD macrosJonas Devlieghere2019-02-201-4/+11
| | | | | | Group LLDB_RECORD macros per input file. llvm-svn: 354423
* [lldb-instr] Don't print REGISTER macro when RECORD is already presentJonas Devlieghere2019-02-191-8/+9
| | | | | | | | | | | Currently we'd always print the LLDB_REGISTER macro, even if the LLDB_RECORD macro was already present. This patches changes that to make it easier to incrementally update the macros. Note that it's still possible for the RECORD and REGISTER macros to get out of sync. llvm-svn: 354400
* [lldb-instr] Wrap returns of struct/classes in LLDB_RECORD_RESULTJonas Devlieghere2019-02-191-3/+42
| | | | | | | The instrumentation framework requires return values of custom classes and structs to be wrapped in the LLDB_RECORD_RESULT macro. llvm-svn: 354301
* One more fix while I'm looking at this - remove the Jason Molenda2019-02-181-7/+1
| | | | | | | | | unused IsSBProcess method, and have IsFBSProcess return false if we don't have API that we can use to make that determination, so we'll try other API if we can. llvm-svn: 354289
* Ah, misunderstood Jonas' feedback - fix this so we'llJason Molenda2019-02-181-1/+2
| | | | | | | do the right thing when both API are available. We want to try both of them if the first one fails. llvm-svn: 354288
* Clean up an unused variable warning when building this forJason Molenda2019-02-181-0/+4
| | | | | | mac native. llvm-svn: 354287
* Add some unconditional logging on the failure points when attachingJason Molenda2019-02-153-42/+69
| | | | | | | | | | | | | | to a process so we'll always get messages in the console logs. Also make the "is frontboard process" / "is backboard process" determination lazy, specifically take it out of the MachProcess::AttachForDebug codepath when we are attaching to a process, to simplify attaching. <rdar://problem/47982516> <rdar://problem/48060134> llvm-svn: 354181
* [lldb] [lldb-server] Catch and report errors from main loopMichal Gorny2019-02-141-1/+6
| | | | | | | | | | Catch the possible error from lldb-gdbserver's main loop, and report it verbosely. Currently, if the loop fails the server exits normally, rendering the problem indistinguishable from regular termination. Differential Revision: https://reviews.llvm.org/D58228 llvm-svn: 354030
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-135-60/+60
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* [lldb-instr] Pass PCHContainerOperations to ClangToolJonas Devlieghere2019-02-122-1/+8
| | | | | | | | | | | | On a local modules build this would cause an error. > fatal error: no handler registered for module format 'obj' > LLVM ERROR: unknown module format Interestingly enough, this didn't trigger on the GreenDragon CMake bot, which is configured with modules. llvm-svn: 353869
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-115-11/+19
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* [lldb] [lldb-instr] Add missing linkage to clang librariesMichal Gorny2019-02-111-0/+3
| | | | | | | | | Fix build errors against shared clang by adding all the libraries used in the code. Differential Revision: https://reviews.llvm.org/D57999 llvm-svn: 353680
* Silence fallthrough warnings in debugserver.Adrian Prantl2019-02-071-1/+4
| | | | llvm-svn: 353468
* Fix some warnings introduced in r353324 (ReproducerInstrumentation patch)Pavel Labath2019-02-071-4/+0
| | | | | | | | | | | | GetIndexForObjectImpl generated a bunch of "conversion casts away constness warnings". Change the function to use "const void *" (and static_cast, while I'm at it), to avoid this. Driver.cpp: unused variable "replay" (this was actually caused by a subsequent partial revert of this patch). I just finish the revert by removing the variable completely. llvm-svn: 353405
* [Driver] Don't try to replay reproducer in the driver.Jonas Devlieghere2019-02-071-9/+0
| | | | | | | Because the macros for the SBReproducers have not been committed yet, the driver should not attempt to replay a reproducer this way. llvm-svn: 353362
* [Reproducers] SBReproducer framework: Capture & ReplayJonas Devlieghere2019-02-061-1/+13
| | | | | | | | | | | | | This is part two of the reproducer instrumentation framework. It contains the code to capture and replay function calls. The main user of this framework will be the SB API layer. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D56322 llvm-svn: 353324
* [Reproducers] lldb-instr: tool to generate instrumentation macros.Jonas Devlieghere2019-02-063-0/+298
| | | | | | | | | | | | | | | | | This patch introduces a new tool called 'lldb-instr'. It automates the workflow of inserting LLDB_RECORD and LLDB_REGSITER macros for instrumentation. Because the tool won't be part of the build process, I didn't want to over-complicate it. SB_RECORD macros are inserted in place, while SB_REGISTER macros are printed to stdout, and have to be manually copied into the Registry's constructor. Additionally, the utility makes no attempt to properly format the inserted macros. Please use clang-format to format the changes after running the tool. Differential revision: https://reviews.llvm.org/D56822 llvm-svn: 353271
* [CMake] Add code signing for lldb-server on iOSStefan Granitz2019-01-281-0/+12
| | | | llvm-svn: 352388
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19322-1288/+966
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [CMake] Prevent lldbDebugserverCommon from building if you disable ↵Alex Langford2019-01-171-85/+84
| | | | | | | | | | | | | | | | | | | | debugserver builds Summary: The flags `LLDB_USE_SYSTEM_DEBUGSERVER` and `LLDB_NO_DEBUGSERVER` were introduced to the debugserver build. If one of these two flags are set, then we do not build and sign debugserver. However I noticed that we were still building the lldbDebugserverCommon and lldbDebugserverCommon_NonUI libraries regardless of whether or not these flags were set. I don't believe we should be building these libraries unless we are building and signing debugserver. Reviewers: sgraenitz, davide, JDevlieghere, beanz, vsk, aprantl, labath Subscribers: mgorny, jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D56763 llvm-svn: 351496
* [lldb-mi] Remove use of dialog boxAlex Langford2019-01-163-24/+0
| | | | | | | | | | | | | | | | Summary: This really is only implemented on Windows, and it requires us to pull in User32. This was only useful when debugging on lldb-mi on Windows, and there doesn't seem to be a good reason why using a dialog box is better than what exists for other platforms. Reviewers: zturner, jingham, compnerd Subscribers: ki.stfu Differential Revision: https://reviews.llvm.org/D56755 llvm-svn: 351276
* [debugserver][CMake] Remove commented out lineAlex Langford2019-01-151-1/+0
| | | | | | | | This has been commented out since rL300111 (commit d742d081f3a1e7412cc609765139ba32d597ac15). Looks like it was committed as a commented out line, so I'm removing it. llvm-svn: 351263
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-141-2/+1
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [SymbolFile] Remove the SymbolContext parameter from FindNamespace.Zachary Turner2019-01-141-2/+1
| | | | | | | | | | | Every callsite was passing an empty SymbolContext, so this parameter had no effect. Inside the DWARF implementation of this function, however, there was one codepath that checked members of the SymbolContext. Since no call-sites actually ever used this functionality, it was essentially dead code, so I've deleted this code path as well. llvm-svn: 351132
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-112-23/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds the glue code necessary to integrate the SymbolFileBreakpad into the plugin system. Most of the methods are stubbed out. The only method implemented method is AddSymbols, which parses the PUBLIC "section" of the breakpad "object file", and fills out the Module's symtab. To enable testing this, I've made two additional changes: - dump Symtab from the SymbolVendor class. The symtab was already being dumped as a part of the object file dump, but that happened before symbol vendor kicked in, so it did not reflect any symbols added there. - add ability to explicitly specify the external symbol file in lldb-test (so that the object file could be linked with the breakpad symbol file). To make things simpler, I've changed lldb-test from consuming multiple inputs (and dumping their symbols) to having it just process a single file per invocation. This was not a problem since everyone was using it that way already. Reviewers: clayborg, zturner, lemo, markmentovai, amccarth Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56173 llvm-svn: 350924
* Implement ObjectFileELF::GetBaseAddressPavel Labath2019-01-101-0/+2
| | | | | | | | | Summary: The concept of a base address was already present in the implementation (it's needed for computing section load addresses properly), but it was never exposed through this function. This fixes that. llvm-svn: 350804
* [lldb-server] Add unnamed pipe support to PipeWindowsAaron Smith2019-01-101-13/+10
| | | | | | | | | | | | | | | | | Summary: This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process. Modify PipeWindows::CreateNew to support the creation of an unnamed pipe. Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed. Reviewers: zturner, llvm-commits Reviewed By: zturner Subscribers: Hui, labath, lldb-commits Differential Revision: https://reviews.llvm.org/D56234 llvm-svn: 350784
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ParseDeclsForContext was originally created to serve the very specific case where the context is a function block. It was never intended to be used for arbitrary DeclContexts, however due to the generic name, the DWARF and PDB plugins implemented it in this way "just in case". Then, lldb-test came along and decided to use it in that way. Related to this, there are a set of functions in the SymbolFile class interface whose requirements and expectations are not documented. For example, if you call ParseCompileUnitFunctions, there's an inherent requirement that you create entries in the underlying clang AST for these functions as well as their signature types, because in order to create an lldb_private::Function object, you have to pass it a CompilerType for the parameter representing the signature. On the other hand, there is no similar requirement (either inherent or documented) if one were to call ParseDeclsForContext. Specifically, if one calls ParseDeclsForContext, and some variable declarations, types, and other things are added to the clang AST, is it necessary to create lldb::Variable, lldb::Type, etc objects representing them? Nobody knows. There is, however, an accidental requirement, because since all of the plugins implemented this just in case, lldb-test came along and used ParsedDeclsForContext, and then wrote check lines that depended on this. When I went to try and implemented the NativePDB reader, I did not adhere to this (in fact, from a layering perspective I went out of my way to avoid it), and as a result the existing DIA PDB tests don't work when the native PDB reader is enabled, because they expect that calling ParseDeclsForContext will modify the *module's* view of symbols, and not just the internal AST. All of this confusion, however, can be avoided if we simply stick to using ParseDeclsForContext for its original intended use case (blocks), and use a different function (ParseAllDebugSymbols) for its intended use case which is, unsuprisingly, to parse all the debug symbols (which is all lldb-test really wanted to do anyway). In the future, I would like to change ParseDeclsForContext to ParseDeclsForFunctionBlock, then delete all of the dead code inside that handles other types of DeclContexts (and probably even assert if the DeclContext is anything other than a block). A few PDB tests needed to be fixed up as a result of this, and this also exposed a couple of bugs in the DIA PDB reader (doesn't matter much since it should be going away soon, but worth mentioning) where the appropriate AST entries weren't being created always. Differential Revision: https://reviews.llvm.org/D56418 llvm-svn: 350764
OpenPOWER on IntegriCloud