summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [lldb] [test] Mark 'reenabled' tests XFAIL on NetBSDMichal Gorny2019-09-045-0/+5
| | | | llvm-svn: 370842
* [lldb] [test] Un-mark two commands/register tests XFAILMichal Gorny2019-09-041-2/+0
| | | | llvm-svn: 370840
* [lldb][NFC] Remove lldbcurses.pyRaphael Isemann2019-09-031-1306/+0
| | | | | | | | | | | | | | | | Summary: This doesn't seem to be used anymore (at least I can't find any reference to this in the LLDB repo and it doesn't seem to be a standalone script). Git says this was once some new curses mode for viewing test results. Reviewers: clayborg, JDevlieghere Reviewed By: JDevlieghere Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67064 llvm-svn: 370804
* [test] Addres TestConcurrentMany*.py flakiness on macOSJonas Devlieghere2019-09-031-16/+11
| | | | | | | | | | On "fast" macOS machines, the TestConcurrentMany*.py tests would fail randomly with different numbers of breakpoints, watchpoints, etc. This seems to be avoidable by giving the threads a little time to breath after the passing the synchronization barrier. This is far from a structural fix but it reduces the flakiness. llvm-svn: 370785
* [test] Remove print statements and verify that the symbol existsJonas Devlieghere2019-09-031-10/+1
| | | | | | | This removes some (commented out) print statements and adds a line that verifies that uses image list to check the symbol. llvm-svn: 370777
* [lldb][NFC] Disable added frame select and all log option test on windowsRaphael Isemann2019-09-032-0/+2
| | | | llvm-svn: 370776
* [lldb] Test 'frame select -r' and fix that INT32_MIN breaks the option parserRaphael Isemann2019-09-033-0/+56
| | | | llvm-svn: 370734
* [lldb][NFC] Test 'command delete'Raphael Isemann2019-09-031-0/+17
| | | | llvm-svn: 370733
* [lldb][NFC] Test that enabling all log options doesn't crash anythingRaphael Isemann2019-09-031-0/+11
| | | | llvm-svn: 370724
* [lldb][NFC] Remove unnecessary constructors from invalid-args testsRaphael Isemann2019-09-033-9/+0
| | | | llvm-svn: 370719
* [lldb][NFC] Simplify script_alias testRaphael Isemann2019-09-031-4/+1
| | | | llvm-svn: 370718
* [lldb][NFC] Also test unaliasing in nested_alias testRaphael Isemann2019-09-031-0/+9
| | | | llvm-svn: 370717
OpenPOWER on IntegriCloud