summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* Revert "[lldb][NFC] Make ApplyObjcCastHack less scary"Jim Ingham2019-09-171-5/+9
| | | | | | | | | | | | | | This reverts commit 21641a2f6dbac22653befd03496e0850537882ff. It was causing the following test failures: lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py lldb-Suite.lang/objc/foundation.TestConstStrings.py lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py llvm-svn: 372057
* [test] Fail gracefully if the regex doesn't matchJonas Devlieghere2019-09-161-6/+11
| | | | | | | | This test is failing on the Fedora bot (staging). Rather than failing with an IndexError, we should trigger an assert and dump the log when the regex doesn't match. llvm-svn: 372052
* Fix swig python package pathHaibo Huang2019-09-161-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The path defined in CMakeLists.txt doesn't match the path generated in our python script. This change fixes that. LLVM_LIBRARY_OUTPUT_INTDIR is defined as: ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX}) On the other hand, the path of site-package is generaged in get_framework_python_dir_windows() in finishSwigPythonLLDB.py as: (Dispite its name, the function is used for everything other than xcode) prefix/cmakeBuildConfiguration/distutils.sysconfig.get_python_lib() From lldb/CMakeLists.txt, we can see that: prefix=${CMAKE_BINARY_DIR}, cmakeBuildConfiguration=${CMAKE_CFG_INTDIR} And from python source code, we can see get_python_lib() always returns lib/pythonx.y/site-packages for posix, or Lib/site-packages for windows: https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L128 We should make them match each other. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67583 llvm-svn: 372047
* [Reproducer] Implement dumping packets.Jonas Devlieghere2019-09-162-3/+25
| | | | | | | | | This patch completes the dump functionality by adding support for dumping a reproducer's GDB remote packets. Differential revision: https://reviews.llvm.org/D67636 llvm-svn: 372046
* Fix warning: lambda capture 'temp_file_path' is not usedJonas Devlieghere2019-09-161-2/+1
| | | | llvm-svn: 372044
* [NFC] Move dumping into GDBRemotePacketJonas Devlieghere2019-09-163-5/+23
| | | | | | | | This moves the dumping logic from the GDBRemoteCommunicationHistory class into the GDBRemotePacket so that it can be reused from the reproducer command object. llvm-svn: 372028
* [lldb] Remove SetCount/ClearCount from FlagsRaphael Isemann2019-09-162-64/+3
| | | | | | | | | | | | | | | | | | Summary: These functions are only used in tests where we should test the actual flag values instead of counting all bits for an approximate check. Also these popcount implementation aren't very efficient and doesn't seem to be optimised to anything fast. Reviewers: davide, JDevlieghere Reviewed By: davide, JDevlieghere Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67540 llvm-svn: 372018
* [lldb][NFC] Make ApplyObjcCastHack less scaryRaphael Isemann2019-09-161-9/+5
| | | | llvm-svn: 372017
* [test] Add -z separate-code to fix tests that ae sensitive to exact ↵Fangrui Song2019-09-166-6/+6
| | | | | | addresses after r371958 llvm-svn: 371962
* [lldb] Code cleanup: FormattersContainer.h: Use range-based for loops.Jan Kratochvil2019-09-141-12/+9
| | | | | | | Suggested for an other loop by Pavel Labath in: https://reviews.llvm.org/D66654#inline-605808 llvm-svn: 371922
* [Reproducer] Add reproducer dump command.Jonas Devlieghere2019-09-134-2/+266
| | | | | | | | | | | This adds a reproducer dump commands which makes it possible to inspect a reproducer from inside LLDB. Currently it supports the Files, Commands and Version providers. I'm planning to add support for the GDB Remote provider in a follow-up patch. Differential revision: https://reviews.llvm.org/D67474 llvm-svn: 371909
* [Reproducer] Move GDB Remote Packet into Utility. (NFC)Jonas Devlieghere2019-09-1317-246/+237
| | | | | | | | | | | | | | To support dumping the reproducer's GDB remote packets, we need the (de)serialization logic to live in Utility rather than the GDB remote plugin. This patch renames StreamGDBRemote to GDBRemote and moves the relevant packet code there. Its uses in the GDBRemoteCommunicationHistory and the GDBRemoteCommunicationReplayServer are updated as well. Differential revision: https://reviews.llvm.org/D67523 llvm-svn: 371907
* [test] Update TestAPILog to pass on Windows.Jonas Devlieghere2019-09-131-2/+2
| | | | | | | The pretty function macro is including __cdecl on Windows, which was causing the pattern matching to fail. This should fix that. llvm-svn: 371905
* [LLDB] Add missing breaks for switch statementTim Shen2019-09-131-0/+3
| | | | llvm-svn: 371902
* [test] Print the log output on failure.Jonas Devlieghere2019-09-131-2/+2
| | | | | | | | This ensures that if the assertion fails we dump the log content. This should help me investigate what the output looks like on Windows, where the test is failing. llvm-svn: 371899
* [Support] Add overload writeFileAtomically(std::function Writer)Jan Korous2019-09-131-22/+28
| | | | | | Differential Revision: https://reviews.llvm.org/D67424 llvm-svn: 371890
OpenPOWER on IntegriCloud