summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] [test] Add NetBSD to XFAIL list for thread_local testMichal Gorny2019-09-251-1/+2
| | | | llvm-svn: 372840
* [lldb] Test data formatters for empty stringsRaphael Isemann2019-09-254-1/+18
| | | | llvm-svn: 372837
* [lldb] Remove -nostdlib++ flag from import-std-module/sysroot testRaphael Isemann2019-09-251-1/+1
| | | | | | | | That flag was introduced in Clang 6.0, so this made the test fail with Clang <= 5.0. As it only influences linking builtin libraries like -m which aren't relevant for this test, we can drop this flag. llvm-svn: 372827
* [lldb][NFC] Refactor TestCallBuiltinFunctionRaphael Isemann2019-09-251-11/+4
| | | | | | Using asserts doesn't print a useful error message in case this test fails. llvm-svn: 372815
* [Make] Revert some changes from r372795.Jonas Devlieghere2019-09-252-4/+4
| | | | | | These changes cause the corresponding test to fail on the Linux bots. llvm-svn: 372801
* Canonicalize variable usage in testsuite MakefilesAdrian Prantl2019-09-25146-219/+264
| | | | | | | | | | | | This test streamlines our use of variables that are expected by Makefile.rules throughout the test suite. Mostly it replaced potentially dangerous overrides and updates of variables like CFLAGS with safe assignments to variables reserved for this purpose like CFLAGS_EXTRAS. Differential Revision: https://reviews.llvm.org/D67984 llvm-svn: 372795
* [CMake] Copy over the system debugserver when using LLDB_USE_SYSTEM_DEBUGSERVERJonas Devlieghere2019-09-244-0/+4
| | | | | | | | | | | | | | | | r366433 broke support for the system debugserver. Although the change was well-intended, it (presumably) unintentionally removed the logic to copy over the debugserver. As a result, even with LLDB_USE_SYSTEM_DEBUGSERVER enabled, we ended up building, signing and using the just-built debugserver. This patch partially recovers the old behavior: when LLDB_USE_SYSTEM_DEBUGSERVER is set we don't build debugserver and just copy over the system one. Differential revision: https://reviews.llvm.org/D67991 llvm-svn: 372786
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-2444-114/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* [lldb][NFC] Relax completion tests for log command to make them pass on LinuxRaphael Isemann2019-09-241-15/+4
| | | | | | | | The log channels change depending on platform, so listing them breaks on some platforms. Let's just check that the 'lldb' and 'dwarf' channels are there which are independent of platform. llvm-svn: 372701
* [lldb] Add completion support for log enable/disable/listRaphael Isemann2019-09-241-0/+32
| | | | | | | | | | | | | | Reviewers: #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67903 llvm-svn: 372691
* Adapt test to upstream clang compiler changes.Adrian Prantl2019-09-241-1/+4
| | | | | | Clang now emits the correct C++ language version in DWARF. llvm-svn: 372677
* [Make] Add support for building NeXT-style frameworksJonas Devlieghere2019-09-231-11/+40
| | | | | | | | | | This patch extends the Makefile.rules to build NeXT-style frameworks. It also fixes a bug in the clean logic that would accidentally delete the .mm source file instead of the .o object file. Thanks a lot to Adrian who was instrumental is getting this to work! llvm-svn: 372669
* [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 that importing decls in a TagDecl end up in wrong declaration ↵Raphael Isemann2019-09-231-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Process formatters in reverse-chronological orderJan Kratochvil2019-09-201-0/+7
| | | | | | | | | | | | 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
* 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
* [lldb] Print better diagnostics for user expressions and modulesRaphael Isemann2019-09-184-1/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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-182-4/+4
| | | | | | | | | | | 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
* [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
* [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
* [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
* [Reproducer] Include the this pointer in the API log.Jonas Devlieghere2019-09-131-0/+48
| | | | | | | | | | | | | | | The new centralized way of doing API logging through the reproducer macros is lacking a way to easily correlate instances of API objects. Logging the this pointer makes that significantly easier. For methods this is now always passed as the first argument, similar to the self argument in Python. This patch also adds a test case for API logging, which uncovered that we were not quoting strings. Differential revision: https://reviews.llvm.org/D67538 llvm-svn: 371885
* The setUp/tearDown methods I added mssed up the test function; reorder.Jason Molenda2019-09-131-6/+7
| | | | | | Thanks to Ted Woodward for catching this one. llvm-svn: 371795
* [lldb][NFC] Simplify makefiles also for breakpoint testsRaphael Isemann2019-09-1230-90/+30
| | | | | | | | These tests were temporarily missing when the big Makefile simplification patch landed, so this just applies the same change to these tests. llvm-svn: 371738
* [lldb] Remove duplicated breakpoint testsRaphael Isemann2019-09-129-502/+0
| | | | | | | | | | | | | | | | | After reverting the deletion of the functionalities/breakpoint tests, we now have some tests twice in the test/ folder which breaks dotest: * commands/breakpoint/basic * functionalities/breakpoint/breakpoint_command After looking over these tests, I think it makes sense to only keep the original functionalities/ folder. The commands/breakpoint/basic test are not exclusively testing the breakpoint command itself, so they shouldn't be in commands/ in the first place. Note that these folders have identical contents (beside small adjustments regarding the Makefile which landed after the restructuring). llvm-svn: 371734
* [DWARF] Evaluate DW_OP_entry_valueVedant Kumar2019-09-114-1/+192
| | | | | | | | | | | | Add support for evaluating DW_OP_entry_value. This involves parsing DW_TAG_call_site_parameter and wiring the information through to the expression evaluator. rdar://54496008 Differential Revision: https://reviews.llvm.org/D67376 llvm-svn: 371668
* Ah, only skip this for embedded darwin targets.Jason Molenda2019-09-111-1/+1
| | | | llvm-svn: 371583
* Skip a test in TestProcessIO.py when running against ios devices.Jason Molenda2019-09-111-0/+1
| | | | llvm-svn: 371582
* [lldbtest] Add an "expected_cmd_failure" option to the filecheck helperVedant Kumar2019-09-101-1/+5
| | | | llvm-svn: 371544
* [lldb] Readd missing functionalities/breakpoint testsRaphael Isemann2019-09-10108-0/+5369
| | | | | | | It seems when I restructured the test folders the functionalities/breakpoint was deleted. This just reverts this change and re-adds the tests. llvm-svn: 371512
* Fix ELF core file memory reading for PT_LOAD program headers with no p_fileszGreg Clayton2019-09-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this fix, ELF files might contain PT_LOAD program headers that had a valid p_vaddr, and a valid file p_offset, but the p_filesz would be zero. For example in llvm-project/lldb/test/testcases/functionalities/postmortem/elf-core/thread_crash/linux-i386.core we see: Program Headers: Index p_type p_flags p_offset p_vaddr p_paddr p_filesz p_memsz p_align ======= ---------------- ---------- ------------------ ------------------ ------------------ ------------------ ------------------ ------------------ [ 0] PT_NOTE 0x00000000 0x0000000000000474 0x0000000000000000 0x0000000000000000 0x0000000000001940 0x0000000000000000 0x0000000000000000 [ 1] PT_LOAD 0x00000005 0x0000000000002000 0x0000000008048000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 2] PT_LOAD 0x00000004 0x0000000000002000 0x000000000804b000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 3] PT_LOAD 0x00000006 0x0000000000002000 0x000000000804c000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 4] PT_LOAD 0x00000006 0x0000000000002000 0x0000000009036000 0x0000000000000000 0x0000000000000000 0x0000000000025000 0x0000000000001000 [ 5] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f63a1000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 6] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f63a2000 0x0000000000000000 0x0000000000000000 0x0000000000800000 0x0000000000001000 [ 7] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f6ba2000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 8] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f6ba3000 0x0000000000000000 0x0000000000000000 0x0000000000804000 0x0000000000001000 [ 9] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f73a7000 0x0000000000000000 0x0000000000000000 0x00000000001b1000 0x0000000000001000 [ 10] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7558000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 11] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 12] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 13] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f755e000 0x0000000000000000 0x0000000000000000 0x0000000000019000 0x0000000000001000 [ 14] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7577000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 15] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7578000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 16] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7579000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 17] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f757b000 0x0000000000000000 0x0000000000000000 0x000000000001c000 0x0000000000001000 [ 18] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7597000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 19] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7598000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 20] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f7599000 0x0000000000000000 0x0000000000000000 0x0000000000053000 0x0000000000001000 [ 21] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f75ec000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 22] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f75ed000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 23] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f75ee000 0x0000000000000000 0x0000000000000000 0x0000000000176000 0x0000000000001000 [ 24] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7764000 0x0000000000000000 0x0000000000000000 0x0000000000006000 0x0000000000001000 [ 25] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 26] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000 [ 27] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f778a000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000 [ 28] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f778c000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000 [ 29] PT_LOAD 0x00000005 0x0000000000004000 0x00000000f778e000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000 [ 30] PT_LOAD 0x00000005 0x0000000000006000 0x00000000f7790000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000 [ 31] PT_LOAD 0x00000004 0x0000000000006000 0x00000000f77b3000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 32] PT_LOAD 0x00000006 0x0000000000006000 0x00000000f77b4000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000 [ 33] PT_LOAD 0x00000006 0x0000000000006000 0x00000000ffa25000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000 Prior to this fix if users tried to read memory from one of these addresses like 0x8048000, they would end up incorrectly reading from the next memory region that actually had a p_filesz which would be 0x00000000f778c000 in this case. This fix correctly doesn't include program headers with zero p_filesz in the ProcessELFCore::m_core_aranges that is used to read memory. I found two cores files that have this same issue and added tests. Differential Revision: https://reviews.llvm.org/D67370 llvm-svn: 371457
* [Windows] Add support of watchpoints to `ProcessWindows`Aleksandr Urakov2019-09-0620-91/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of watchpoints to the old `ProcessWindows` plugin. The `ProcessWindows` plugin uses the `RegisterContext` to set and reset watchpoints. The `RegisterContext` has some interface to access watchpoints, but it is very limited (e.g. it is impossible to retrieve the last triggered watchpoint with it), that's why I have implemented a slightly different interface in the `RegisterContextWindows`. Moreover, I have made the `ProcessWindows` plugin responsible for search of a vacant watchpoint slot, because watchpoints exist per-process (not per-thread), then we can place the same watchpoint in the same slot in different threads. With this scheme threads don't need to have their own watchpoint lists, and it simplifies identifying of the last triggered watchpoint. Reviewers: asmith, stella.stamenova, amccarth Reviewed By: amccarth Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67168 llvm-svn: 371166
* Remove `bugreport` commandJonas Devlieghere2019-09-051-1/+1
| | | | | | | | | | | | The bugreport command exists to create domain-specific bug reports. Currently it has one implementation for filing bugs on the unwinder. As far as we can tell, it has never been of use. Although not exactly the same as the reproducers, it's a bit confusing to have two parallel command trees for (kind of) the same thing. Differential revision: https://reviews.llvm.org/D65469 llvm-svn: 371132
* [lldb][NFC] Add dimensions to pexpect tests failing on sanitizer botRaphael Isemann2019-09-052-2/+2
| | | | | | | | | | I'm still unable to reproduce this locally, so let's see if this is enough to make the bots happy. The missing dimension parameter seems to be the biggest difference between these tests and TestIOHandlerCompletion.py which runs just fine on the same bot, so that's the motivation for trying this out. llvm-svn: 371077
* [lldb][NFC] Stabilize gui/basic test by waiting on promptRaphael Isemann2019-09-051-0/+1
| | | | | | We should wait on the GUI to exit before tearing down the test. llvm-svn: 371028
* [dotest] Remove top-level MakefilePavel Labath2019-09-051-32/+0
| | | | | | | | This appears to be a really ancient way of running the test suite. It is also completely disfunctional now, and probably has been for a long time. llvm-svn: 371020
* [dotest] Centralize initialization commands even morePavel Labath2019-09-054-28/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: In r367234 we introduced a central place to hold the set up commands for the various ways we have of launching lldb. However, a number of commands still remained outside of that. This patch moves the remaining set up commands into this function, which allows us to remove manual clang module path setting code in TestBatchMode. One unfortunate victim of this approach is TestSTTYBeforeAndAfter which, due to how it launches lldb (pexpect->expect->lldb), fails get the quoting right. It would be possible to fix the quoting there, it would be a bit icky, and none of the commands in this list are really relevant for what this test is doing, so I just remove the commands outright. Reviewers: JDevlieghere, jankratochvil Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67173 llvm-svn: 371019
* [dotest] Delete trivial inline test makefilesPavel Labath2019-09-0530-77/+0
| | | | | | inline tests are able to generate these automatically llvm-svn: 371015
* [test] Escape path to match the literal stringJonas Devlieghere2019-09-041-1/+1
| | | | | | This test was failing when you had things like `+` in your build path. llvm-svn: 370983
* Revert "[test] Address TestConcurrentMany*.py flakiness on macOS"Jonas Devlieghere2019-09-041-9/+16
| | | | | | | This reverts my change to pseudo_barrier.h which isn't necessary anymore after Fred's fix to debugserver and caused TestThreadStepOut to fail. llvm-svn: 370963
* [Python] Implement __next__ for value_iterJonas Devlieghere2019-09-041-0/+7
| | | | | | | | | Python 3 iteration calls the next() method instead of next() and value_iter only implemented the Python 2 version. Differential revision: https://reviews.llvm.org/D67184 llvm-svn: 370954
* [Python] Implement truth testing for lldb.valueJonas Devlieghere2019-09-041-0/+4
| | | | | | | | | Python 3 calls __bool__() instead of __len__() and lldb.value only implemented the __len__ method. This adds the __bool__() implementation. Differential revision: https://reviews.llvm.org/D67183 llvm-svn: 370953
* Upstream macCatalyst support in debugserver and the macOS dynamic loaderAdrian Prantl2019-09-048-2/+78
| | | | | | | | | | | plugin. Unfortunately the test is currently XFAILed because of missing changes to the clang driver. Differential Revision: https://reviews.llvm.org/D67124 llvm-svn: 370931
* Workaround TestConcurrentMany* flakiness in a more pricipled wayFrederic Riss2019-09-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | The flakiness on our local machines seems to come for a race in the kernel between task_suspend and the creation of the Mach exceptions for the threads that hit breakpoints. The debugserver code is written with the assumption that the kernel will be able to provide us with all the exceptions for a given task once task_suspend returns. On machines with higher core counts, this seems not to be the case. The first batch of exceptions we get after task_suspend does not contain exceptions for all the threads that have hit a breakpoint, thus they get misreprorted in the first stop packet. Adding a 1ms timeout to the call that retrieves the batch of exceptions seems to workaround the issue reliably on our machines, and it shoulnd't impact standard debugging scenarios too much (a stop will incur an additional 1ms delay). We'll be talking to the kernel team to figure out the right contract for those APIs. This patch also reverts part of Jonas' previous workaround for the issue (r370785). llvm-svn: 370916
* [lldb] Limit the amount of zeroes we use for padding when printing small floatsRaphael Isemann2019-09-043-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We got a radar that printing small floats is not very user-friendly in LLDB as we print them with up to 100 leading zeroes before starting to use scientific notation. This patch changes this by already using scientific notation when we hit 6 padding zeroes by default and moves this value into a target setting so that users can just set this number back to 100 if they for some reason preferred the old behaviour. This new setting is influencing how we format data, so that's why we have to reset the data visualisation cache when it is changed. Note that we have always been using scientific notation for large numbers because it seems that the LLVM implementation doesn't support printing out the padding zeroes for them. I would have fixed that if it was trivial, but looking at the LLVM implementation for this it seems that this is not as trivial as it sounds. I would say we look into this if we ever get a bug report about someone wanting to have a large amount of trailing zeroes in their numbers instead of using scientific notation. Fixes rdar://39744137 Reviewers: #lldb, clayborg Reviewed By: clayborg Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67001 llvm-svn: 370880
* Port TestBatchMode to PExpectTest classPavel Labath2019-09-042-91/+56
| | | | | | | | | | | | | | | Summary: I'm doing this mainly for consistency, but there are also other cleanups that will be enabled by this (e.g., the automatic setting of clang-modules-cache-path setting). Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67082 llvm-svn: 370858
* [lldb][NFC] Add a simple test for thread_local storage.Raphael Isemann2019-09-043-0/+25
| | | | | | | Seems we fail to read TLS data on Linux, so the test only runs on macOS for now. We will see how this test runs on the BSD bots. llvm-svn: 370848
* [dotest] Avoid the need for LEVEL= makefile boilerplatePavel Labath2019-09-04557-1581/+552
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of each test case knowing its depth relative to the test root, we can just have dotest add the folder containing Makefile.rules to the include path. This was motivated by r370616, though I have been wanting to do this ever since we moved to building tests out-of-tree. The only manually modified files in this patch are lldbinline.py and plugins/builder_base.py. The rest of the patch has been produced by this shell command: find . \( -name Makefile -o -name '*.mk' \) -exec sed --in-place -e '/LEVEL *:\?=/d' -e '1,2{/^$/d}' -e 's,\$(LEVEL)/,,' {} + Reviewers: teemperor, aprantl, espindola, jfb Subscribers: emaste, javed.absar, arichardson, christof, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D67083 llvm-svn: 370845
OpenPOWER on IntegriCloud