summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* [Host] File::GetWaitableHandle() should call fileno()Jonas Devlieghere2019-09-233-1/+38
| | | | | | | | | | | | If the file has m_stream, it may not have a m_descriptor. GetWaitableHandle() should call GetDescriptor(), which will call fileno(), so it will get waitable descriptor whenever one is available. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67789 llvm-svn: 372644
* [ABISysV] Fix regression for Simulator and MacABIJonas Devlieghere2019-09-231-7/+23
| | | | | | | | | | | | | | | The ABISysV ABI was refactored in r364216 to support the Windows ABI for x86_64. In particular it changed ABISysV_x86_64::CreateInstance to switch on the OS type. This breaks debugging MacABI apps as well as apps in the simulator. This adds back the necessary cases. We have a test on Github that exercises this code path and which I'd like to upstream once the remaining MacABI parts become available in clang. Differential revision: https://reviews.llvm.org/D67869 llvm-svn: 372642
* [lldb-suite] TestCallOverriddenMethod.py is now passing on WindowsStella Stamenova2019-09-231-1/+0
| | | | | | The test is now passing, so remove the expected failure. No other tests associated with the bug are passing, though, so only remove expected failure from this one test llvm-svn: 372634
* [LLDB] Fix logically dead codeKonrad Kleine2019-09-231-3/+0
| | | | | | | | | | | | | | | | | | | Summary: The indicated dead code may have performed some action; that action will never occur. In lldb_private::LoadedModuleInfoList::LoadedModuleInfo::operator ==(lldb_private::LoadedModuleInfoList::LoadedModuleInfo const &): Code can never be reached because of a logical contradiction (CWE-561) Coverity Scan: https://scan.coverity.com/projects/kwk-llvm-project?tab=overview CID 221581 Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67915 llvm-svn: 372608
* [LLDB] Check for _WIN32 instead of _MSC_VER for code specific to windows in ↵Martin Storsjo2019-09-235-9/+9
| | | | | | | | | | | general These ifdefs contain code that isn't specific to MSVC but useful for any windows target, like MinGW. Differential Revision: https://reviews.llvm.org/D67893 llvm-svn: 372592
* [LLDB] Remove a now redundant windows specific workaroundMartin Storsjo2019-09-231-5/+0
| | | | | | | | | | | | | | | | vsnprintf(NULL, 0, ...) works for measuring the needed string size on all supported Windows variants; it's supported since at least MSVC 2015 (and LLVM requires a newer version than that), and works on both msvcrt.dll (since at least XP) and UCRT with MinGW. The previous use of ifdefs was wrong as well, as __MINGW64__ only is defined for 64 bit targets, and the define without trailing underscores is never defined automatically (neither by clang nor by gcc). Differential Revision: https://reviews.llvm.org/D67861 llvm-svn: 372591
* [LLDB] Add a void* cast when passing object pointers to printf %pMartin Storsjo2019-09-231-14/+10
| | | | | | | | | | This fixes build warnings in MinGW mode. Also remove leftover if (log) {} around the log macro. Differential Revision: https://reviews.llvm.org/D67896 llvm-svn: 372590
* [LLDB] Avoid a warning about an unused static variableMartin Storsjo2019-09-231-1/+1
| | | | | | | | The variable is unused on windows. Differential Revision: https://reviews.llvm.org/D67895 llvm-svn: 372589
* [LLDB] Remove a stray semicolon. NFC.Martin Storsjo2019-09-231-1/+1
| | | | | | This fixes build warnings with at least GCC. llvm-svn: 372588
* [LLDB] Add a missing specification of linking against dbghelpMartin Storsjo2019-09-231-0/+8
| | | | | | | | | | | | | | | | | | | The PECOFF object file plugin uses the dbghelp API, but doesn't specify that it has to be linked in anywhere. Current MSVC based builds have probably succeeded, as other parts in LLDB have had a "#pragma comment(lib, "dbghelp.lib")", but there's currently no such pragma in the PECOFF plugin. The "#pragma comment(lib, ...)" approach doesn't work in MinGW mode (unless the compiler is given the -fms-extensions option, and even then, it's only supported by clang/lld, not by GCC/binutils), thus add it to be linked via CMake. (The other parts of LLDB that use dbghelp are within _MSC_VER ifdefs.) Differential Revision: https://reviews.llvm.org/D67885 llvm-svn: 372587
* [LLDB] Use the Windows SOCKET type on all windows targets, not only MSVCMartin Storsjo2019-09-231-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D67859 llvm-svn: 372586
* [lldb][NFC] Remove unused variable in Options::HandleOptionArgumentCompletionRaphael Isemann2019-09-231-1/+0
| | | | llvm-svn: 372574
* [lldb][NFC] Remove dead code in Options::HandleOptionArgumentCompletionRaphael Isemann2019-09-231-9/+2
| | | | llvm-svn: 372572
* [lldb][NFC] Fix documentation of CompletionRequest::AddCompletionRaphael Isemann2019-09-231-1/+2
| | | | llvm-svn: 372569
* [lldb][NFC] Make cursor char position unsigned in CompletionRequestRaphael Isemann2019-09-232-6/+6
| | | | | | | This was only an 'int' because to fit into the old API which is gone by now. llvm-svn: 372568
* [lldb] Make cursor index in CompletionRequest unsignedRaphael Isemann2019-09-236-35/+46
| | | | | | | | | | | | The fact that index==-1 means "no arguments" is not obvious and only used in one place from what I can tell. Also fixes several warnings about using the cursor index as if it was a size_t when comparing. Not fully NFC as we now also correctly update the partial argument list when injecting the fake empty argument in the CompletionRequest constructor. llvm-svn: 372566
* [lldb][NFC] Remove argument prefix checking boilerplate when adding completionsRaphael Isemann2019-09-238-30/+64
| | | | llvm-svn: 372561
* [lldb] Reduce some dangerous boilerplate with CompletionRequest::ShiftArgumentsRaphael Isemann2019-09-235-6/+45
| | | | | | | | | | | | | We should in general not allow external code to fiddle with the internals of CompletionRequest, but until this is gone let's at least provide a utility function that makes this less dangerous. This also now correct updates the partially parsed argument list, but it doesn't seem to be used by anything that is behind one of the current shift/SetCursorIndex calls, so this doesn't seeem to fix any currently used completion. llvm-svn: 372556
* [lldb] Fix that importing decls in a TagDecl end up in wrong declaration ↵Raphael Isemann2019-09-232-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context (partly reverts D61333) Summary: In D61333 we dropped some code from ClangASTSource that checks if imported declarations ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit by the test suite but we didn't have any checks that were affected) and the code seems pointless (as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map). This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests which is currently the most reliable way to test this problem (it's a tricky setup, see description below). Fixes rdar://55502701 and rdar://55129537 -------------------------------------- Some more explanation what is actually going on and what is going wrong: The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map (even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no members. However, `frame var m` works just fine (and fixes all following `expr m` calls). The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST). When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen. This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import the `first` and `second` members as we don't need them for anything). After the expression is done, we take the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members. We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However, P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST). So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first `std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations and just print an empty map as a fallback. The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes the formatters happy as they can now see the members in the DeclContext they are querying. Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this. Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can tell), but that might have unintended side-effects and not sure what's the best way to implement this. Reviewers: friss, martong Reviewed By: martong Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik Tags: #lldb Differential Revision: https://reviews.llvm.org/D67803 llvm-svn: 372549
* [lldb] Fix LLDB build after r372538Raphael Isemann2019-09-231-1/+2
| | | | llvm-svn: 372548
* Use _WIN32 instead of _MSC_VERHaibo Huang2019-09-221-1/+1
| | | | | | | | | | | | Summary: This way it works better with MinGW. Subscribers: mstorsjo, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67887 llvm-svn: 372493
* [LLDB] Cast -1 (as invalid socket) to the socket type before comparingMartin Storsjo2019-09-212-6/+7
| | | | | | | | | | This silences warnings about comparison of integers between unsigned long long (which is what the Windows SOCKET type is) and signed int when building in MinGW mode. Differential Revision: https://reviews.llvm.org/D67863 llvm-svn: 372486
* [LLDB] Use SetErrorStringWithFormatv for cases that use LLVM style format ↵Martin Storsjo2019-09-212-6/+6
| | | | | | | | | | | strings SetErrorStringWithFormat only supports normal printf style format strings. Differential Revision: https://reviews.llvm.org/D67862 llvm-svn: 372485
* [LLDB] Use LLVM_FALLTHROUGH instead of a custom commentMartin Storsjo2019-09-211-1/+1
| | | | | | | | This fixes a warning when built with Clang in MinGW mode. Differential Revision: https://reviews.llvm.org/D67860 llvm-svn: 372484
* [LLDB] Check for the GCC/MinGW compatible arch defines for windows, in ↵Martin Storsjo2019-09-212-5/+5
| | | | | | | | | | | addition to MSVC defines This matches how it is done in all other similar ifdefs throughout lldb. Differential Revision: https://reviews.llvm.org/D67858 llvm-svn: 372483
* [LLDB] Fix compilation for MinGW, remove redundant class name on inline memberMartin Storsjo2019-09-211-1/+1
| | | | | | | | | | | | This fixes build errors like these: NativeRegisterContextWindows.h:22:33: error: extra qualification on member 'NativeRegisterContextWindows' NativeRegisterContextWindows::NativeRegisterContextWindows( ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ Differential Revision: https://reviews.llvm.org/D67856 llvm-svn: 372482
* prepare_binding_Python: print readable errors if SWIG failsJonas Devlieghere2019-09-201-4/+6
| | | | | | | | | | | | When swig fails, all the errors are squished onto one line with \n quoting. It's very hard to read. This will print them out in a more reasonable format. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67790 llvm-svn: 372442
* dotest.py: bugfix: test filters with -f do not work on Python3Jonas Devlieghere2019-09-201-1/+1
| | | | | | | | | | | | | | | | dotest -f does not work on Python3. The name types.UnboundMethodType was an alias for types.MethodType in 2.7, but it does not exist in python3. MethodType works in both. Also the actual type returned from SomeClass.some_method in python3 will be types.Function, not MethodType. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67791 llvm-svn: 372441
* [lldb] Process formatters in reverse-chronological orderJan Kratochvil2019-09-203-39/+34
| | | | | | | | | | | | If one reverts D66398 then the TestDataFormatterStdList does fail - as the C++ formatters are initialized in the opposite order. But the current state of trunk does not mind the order for C++ formatters. It is using now a single std::vector as suggested by Pavel Labath. Differential Revision: https://reviews.llvm.org/D66654 llvm-svn: 372424
* Doxygenify comments.Adrian Prantl2019-09-202-43/+47
| | | | llvm-svn: 372411
* Move decl completion out of the ASTImporterDelegate and document it [NFC]Raphael Isemann2019-09-202-129/+127
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ASTImporterDelegate is currently responsible for both recording and also completing types. This patch moves the actual completion and recording code outside the ASTImporterDelegate to reduce the amount of responsibilities the ASTImporterDelegate has to fulfill. As I anyway had to touch the code when moving I also documented and refactored most of it (e.g. no more asserts that we call the deporting start/end function always as a pair). Note that I had to make the ASTImporterDelegate and it's related functions public now so that I can move out the functionality in another class (that doesn't need to be in the header). Reviewers: shafik, aprantl, martong, a.sidorin Reviewed By: martong Subscribers: rnkovacs, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61478 llvm-svn: 372385
* [lldb][NFC] Remove unused include in TestLineEntry.cppRaphael Isemann2019-09-201-1/+0
| | | | llvm-svn: 372381
* Revert "Fix swig python package path"Haibo Huang2019-09-201-6/+4
| | | | | | | | | | | | | | Summary: This reverts commit 5a115e81cdd40c758b10c382aeffc0c8de6930e2. Reviewers: JDevlieghere, ZeGentzy Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67781 llvm-svn: 372364
* [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBERMichal Gorny2019-09-191-3/+4
| | | | | | | | Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER. Differential Revision: https://reviews.llvm.org/D67727 llvm-svn: 372300
* Fir TestAPILog for gccPavel Labath2019-09-181-7/+5
| | | | | | | | | | | different compilers will put different things into __PRETTY_FUNCTION__. For instance gcc will not put a " " in the "const char *" argument, causing our regex matching to fail. This patch relaxes the regexes in this test to account for this difference. llvm-svn: 372224
* Fix command-script-import.test on linuxPavel Labath2019-09-183-7/+7
| | | | | | | | | | | | | | | | | | The test was expecting the value of "lldb.frame" to be None, because it is cleared after each python interpreter session. However, this is not true in the very first session, because lldb.py sets these values to invalid objects (lldb.SBFrame(), etc.). I have not investigated why is it that this test passes on darwin, but my guess is that this is because we do extra work on darwin (loading the objc runtime, etc), which causes us to enter the python interpreter sooner. This patch changes lldb.py to also initialize these values to None, as that seems to make more sense. I also fixed some typos in the test while I was in there. llvm-svn: 372222
* [lldb] Fix a test assertion after r372192Krasimir Georgiev2019-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `CHECK: frame:py: None` seems to have been a typo, causing build bot failures: ``` # CHECK: frame:py: None ^ <stdin>:1:1: note: scanning from here (lldb) command source -s 0 'E:/build_slave/lldb-x64-windows-ninja/build/tools/lldb\lit\lit-lldb-init' ^ <stdin>:23:1: note: possible intended match here frame:py: No value ^ ``` This update fixes the build bots. -- Reviewers: bkramer Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D67702 llvm-svn: 372221
* [lldb][CMake] Build LLDB.framework with -Wdocumentation in XcodeStefan Granitz2019-09-181-0/+3
| | | | llvm-svn: 372213
* [lldb][CMake] Infer `Clang_DIR` if not passed explicitlyStefan Granitz2019-09-182-9/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: If we only get `LLVM_DIR` and find Clang in the same provided build-tree, automatically infer `Clang_DIR` like this: ``` LLVM_DIR = /path/to/build-llvm/lib/cmake/llvm Clang_DIR = /paht/to/build-llvm/lib/cmake/clang ``` Reviewers: JDevlieghere, jingham, xiaobai, compnerd, labath Reviewed By: JDevlieghere, labath Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65798 llvm-svn: 372210
* [lldb] Print better diagnostics for user expressions and modulesRaphael Isemann2019-09-1812-69/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions. For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: invalid operands to binary expression ('int' and 'double') ``` This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this: ``` (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float') printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3) ~~~~~~^~~~ ``` To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to our internal wrapper code we inject. Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function) will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible. We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message without any context (and the original diagnostic in the user expression should be enough to explain the issue). Fixes rdar://24306342 Reviewers: JDevlieghere, aprantl, shafik, #lldb Reviewed By: JDevlieghere, #lldb Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65646 llvm-svn: 372203
* Clean up this test.Jim Ingham2019-09-181-46/+11
| | | | | | | | | | | | | I don't know what the intent of parts of this test were. We set a bunch of breakpoints and ran from one to the other, doing "self.runCmd("thread backtrace")" then continuing to the next one. We didn't actually verify the contents of the backtrace, nor that we hit the breakpoints we set in any particular order. The only actual test was to run sel_getName at two of these stops. So I reduced the test to just stopping at the places where we were actually going to run an expression, and tested the expression. llvm-svn: 372196
* Cache PYTHON_EXECUTABLE for windowsHaibo Huang2019-09-181-4/+4
| | | | | | | | | | | | Summary: This way it can be overwritten when cross compiling. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67641 llvm-svn: 372194
* TestFoundationDisassembly.py is not dependent on debug information.Jim Ingham2019-09-181-0/+2
| | | | | | | This test is about disassembling symbols in a framework without debug information. So we don't need to run it once per debug info flavor. llvm-svn: 372193
* [ScriptInterpreter] Limit LLDB's globals to interactive mode.Jonas Devlieghere2019-09-185-13/+21
| | | | | | | | | | | Jim pointed out that the LLDB global variables should only be available in interactive mode. When used from a command for example, their values might be stale or not at all what the user expects. Therefore we want to explicitly make these variables unavailable. Differential revision: https://reviews.llvm.org/D67685 llvm-svn: 372192
* [ScriptInterpreter] Remove ScriptInterpreterPythonImpl::Clear() (NFC)Jonas Devlieghere2019-09-182-14/+0
| | | | | | This method is never called. llvm-svn: 372190
* lldb: move a test input to the test Inputs dirKrasimir Georgiev2019-09-172-1/+3
| | | | | | | | | | Summary: This makes the input file for a new test added in r372060 directly available in the Inputs subdirectory of the test dir. Differential Revision: https://reviews.llvm.org/D67655 llvm-svn: 372112
* [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action listMichal Gorny2019-09-171-2/+3
| | | | | | | | | | Fix processing of "C" packet with signal for the whole process to default signal value for action list to LLDB_INVALID_SIGNAL_NUMBER rather than 0. Differential Revision: https://reviews.llvm.org/D67625 llvm-svn: 372090
* Reland "[lldb][NFC] Make ApplyObjcCastHack less scary"Raphael Isemann2019-09-171-9/+5
| | | | | | First version had a typo. llvm-svn: 372077
* [test] Disable reproducer dump test on WindowsJonas Devlieghere2019-09-171-0/+1
| | | | llvm-svn: 372064
* [ScriptInterpreter] Initialize globals when loading a scripting module.Jonas Devlieghere2019-09-173-6/+16
| | | | | | | | | | | | | The LoadScriptingModule used by command script import wasn't initializing the LLDB global variables (things like `lldb.frame` and `lldb.debugger`). They would get initialized however when running the interactive script interpreter or running a single script line (e.g. `script print(lldb.frame)`). This patch fixes that by properly initializing the globals when loading a Python module. Differential revision: https://reviews.llvm.org/D67644 llvm-svn: 372060
OpenPOWER on IntegriCloud