summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite
Commit message (Collapse)AuthorAgeFilesLines
...
* Pass an SBStructuredData to scripted ThreadPlans on use.Jim Ingham2019-10-033-7/+38
| | | | | | | | | | This will allow us to write reusable scripted ThreadPlans, since you can use key/value pairs with known keys in the plan to parametrize its behavior. Differential Revision: https://reviews.llvm.org/D68366 llvm-svn: 373675
* Break out the Python class & key/value options into a separate OptionGroup.Jim Ingham2019-10-032-0/+21
| | | | | | | | | | Use this in the scripted breakpoint command. Added some tests for parsing the key/value options. This uncovered a bug in handling parsing errors mid-line. I also fixed that bug. Differential Revision: https://reviews.llvm.org/D68363 llvm-svn: 373673
* SBDebugger::SetInputFile, SetOutputFile, etc.Lawrence D'Anna2019-10-031-1/+125
| | | | | | | | | | | | | | | | | | | | | Summary: Add new methods to SBDebugger to set IO files as SBFiles instead of as FILE* streams. In future commits, the FILE* methods will be deprecated and these will become the primary way to set the debugger I/O streams. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68181 llvm-svn: 373563
* new api class: SBFileLawrence D'Anna2019-10-032-0/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SBFile is a scripting API wrapper for lldb_private::File This is the first step in a project to enable arbitrary python io.IOBase file objects -- including those that override the read() and write() methods -- to be used as the main debugger IOStreams. Currently this is impossible because python file objects must first be converted into FILE* streams by SWIG in order to be passed into the debugger. full prototype: https://github.com/smoofra/llvm-project/tree/files Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67793 llvm-svn: 373562
* [lldb] Fix evaluation of nested classes with parent from other CURaphael Isemann2019-10-025-0/+81
| | | | | | | | | | | | | | This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context. Without this fix, nested classes can be dumped directly into their CU context if their parent was imported from another CU. Reviewed By: teemperor, labath Differential Revision: https://reviews.llvm.org/D68278 Patch by Jaroslav Sevcik! llvm-svn: 373470
* Allow the internal-state-thread free access to the TargetAPI mutex.Jim Ingham2019-10-013-10/+74
| | | | | | | | | | | It is always doing work on behalf of another thread that presumably has the mutex, so if it is calling SB API's it should have free access to the mutex. This is the same decision as we made earlier with the process RunLock. Differential Revision: https://reviews.llvm.org/D68174 llvm-svn: 373280
* [test] Make TestBasicEntryValuesX86_64 run on Linux as well as DarwinVedant Kumar2019-09-301-1/+5
| | | | | | | I think a reasonable plan here is to add support for OSes following the SysV ABI one by one, watching the bots as we go. llvm-svn: 373233
* [lldb][NFC] Updating test to reflect made by D67966Shafik Yaghmour2019-09-301-1/+1
| | | | | | | Summary: D67966 changes the output when dumping DWARF expressions and this updates basic_entry_values_x86_64 test to reflect this change. llvm-svn: 373229
* [lldb] Reland 370734: Test 'frame select -r' and fix that INT32_MIN breaks ↵Raphael Isemann2019-09-301-0/+43
| | | | | | | | | | | | | the option parser The problem with r370734 was that it removed the code for resetting the options in OptionParsingStarting. This caused that once a 'frame select -r ...' command was executed, we kept the relative index argument for all following 'frame select ...' invocations (even the ones with an absolute index as they are the same command object). See rdar://55791276. This relands the patch but keeps the code that resets the command options before execution. llvm-svn: 373201
* [lldb] Partly revert 370734: Test 'frame select -r' and fix that INT32_MIN ↵Raphael Isemann2019-09-301-4/+0
| | | | | | | | | | | breaks the option parser This somehow caused that 'frame select X' ends up being interpreted as 'frame select -r 1' when 'up' or 'down' were run before 'frame select X'. See rdar://55791276. Partly reverting to unbreak master. The changes that aren't reverted are the generic 'frame select -r' tests that are obviously NFC and test existing behavior. llvm-svn: 373194
* [lldb][clang][modern-type-lookup] Use ASTImporterSharedState in ↵Raphael Isemann2019-09-303-0/+29
| | | | | | | | | | | | | | | | | | ExternalASTMerger Summary: The ExternalASTMerger should use the ASTImporterSharedState. This allows it to handle std::pair in LLDB (but the rest of libc++ is still work in progress). Reviewers: martong, shafik, a.sidorin Subscribers: rnkovacs, christof, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68140 llvm-svn: 373193
* Give an error when StepUsingScriptedThreadPlan is passed a bad classname.Jim Ingham2019-09-281-1/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D68173 llvm-svn: 373135
* Revert: [lldb] [testsuite] Remove redundant MAKE_DSYM := NOJan Kratochvil2019-09-2717-0/+22
| | | | | | | | | | Revert: llvm-svn: 373061 It broke OSX testsuite: https://reviews.llvm.org/D67589#1686150 lldb/packages/Python/lldbsuite/test/macosx/function-starts/TestFunctionStarts.py llvm-svn: 373110
* [lldb] Disable testing entry values as memory locationDjordje Todorovic2019-09-271-0/+3
| | | | | | The D67717 excludes such locations for now. llvm-svn: 373074
* Disable the empty string check in TestDataFormatterStdStringPavel Labath2019-09-271-1/+2
| | | | | | | This check was failing since it was added in r372837. It should be possible to re-enable it once D68010 lands. llvm-svn: 373071
* [lldb] [testsuite] Remove redundant MAKE_DSYM := NOJan Kratochvil2019-09-2717-22/+0
| | | | | | | According to a comment by Pavel Labath: https://reviews.llvm.org/D67589#inline-612375 llvm-svn: 373061
* [lldb] Print an error message for an empty subcommandRaphael Isemann2019-09-271-2/+1
| | | | llvm-svn: 373053
* [lldb][NFC] Actually test which method we call in TestCallOverriddenMethodRaphael Isemann2019-09-272-4/+8
| | | | llvm-svn: 373051
* [lldb][NFC] Test CommandObjectMultiword functionalityRaphael Isemann2019-09-271-0/+34
| | | | | | | | A lot of commands are made up of CommandObjectMultiword with subcommands. CommandObjectMultiword actually has some functionality on its own that wasn't tested before. llvm-svn: 373050
* [lldb][modern-type-lookup] Add test for using the ClangModulesDeclVendorRaphael Isemann2019-09-263-0/+36
| | | | llvm-svn: 372965
* Don't stop execution in batch mode when process stops with SIGINT or SIGSTOPTatyana Krasnukha2019-09-261-0/+29
| | | | | | | | Summary: Usually, SIGINT and SIGSTOP don't imply a crash, e.g. SIGSTOP is sent on process launch and attach on some platforms. Differential Revision: https://reviews.llvm.org/D67776 llvm-svn: 372961
* Modernize Makefile.Adrian Prantl2019-09-251-1/+1
| | | | llvm-svn: 372890
* [lldb][modern-type-lookup] Add two basic tests for modern-type-lookupRaphael Isemann2019-09-256-0/+69
| | | | | | | | | | | | | | | | | | The story so far: LLDB's modern type lookup mode has no (as in, 0%) test coverage. It was supposed to be tested by hardcoding the default to 'true' and then running the normal LLDB tests, but to my knowledge no one is doing that. As a around 130 tests seem to fail with this mode enabled, we also can't just enable it globally for now. As we touch the surrounding code all the time and also want to refactor parts of it, we should be a bit more ambitious with our testing efforts. So this patch adds two basic tests that enable this mode and do some basic expression parsing which should hopefully be basic enough to not break anywhere but still lets us know if this mode works at all (i.e. setting up the ExternalASTMerger in LLDB, using its basic import functionality to move declarations around and do some lookups). llvm-svn: 372869
* [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
OpenPOWER on IntegriCloud