summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
...
* [lit] Remove the *.test suffix from two test inputsVedant Kumar2018-05-313-4/+4
| | | | | | | This prevents the test inputs from being marked as unsupported tests, due to their lack of RUN lines. llvm-svn: 333701
* [IRMemoryMap] Test interleaved Mallocs and FreesVedant Kumar2018-05-312-0/+280
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a new command to the ir-memory-map tester: free <allocation-index> The argument to free is an index which identifies which live allocation to free. Index 0 identifies the first live allocation in the address space, index 1 identifies the second, etc. where the allocations are sorted in increasing order. For illustrative purposes, assume malloc returns monotonically increasing addresses. Here are some examples of how free would work: Example 1 --------- malloc 16 1 malloc 32 1 free 1 //< Free the 32-byte allocation. free 0 //< Next, free the 16-byte allocation. Example 2 --------- malloc 16 1 malloc 32 1 free 0 //< Free the 16-byte allocation. free 0 //< Next, free the 32-byte allocation. llvm-svn: 333700
* [IRMemoryMap] Test host-side allocationsVedant Kumar2018-05-311-0/+2
| | | | | | | | r333583 introduced testing for IRMemoryMap's process-side allocations (eAllocationPolicyProcessOnly). This adds support for the host-side variety (eAllocationPolicyHostOnly). llvm-svn: 333698
* [IRMemoryMap] Fix the alignment adjustment in MallocVedant Kumar2018-05-313-27/+37
| | | | | | | | | | | | | | | | | | | | This prevents Malloc from allocating the same chunk of memory twice, as a byproduct of an alignment adjustment which gave the client access to unallocated memory. Prior to this patch, the newly-added test failed with: $ lldb-test ir-memory-map ... ir-memory-map-overlap1.test ... Command: malloc(size=64, alignment=32) Malloc: address = 0x1000cd080 Command: malloc(size=64, alignment=8) Malloc: address = 0x1000cd0b0 Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0) Differential Revision: https://reviews.llvm.org/D47551 llvm-svn: 333697
* [lldb-test] Add a testing harness for the JIT's IRMemoryMapVedant Kumar2018-05-301-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
* [lit] Add support for passing arguments to dotest.py via lit.Jonas Devlieghere2018-05-291-0/+8
| | | | | | | | | | | | | | | | The lldb test suite is highly configurable. While part of this configuration takes place at configure/build-time, a common scenario involves running the test suite several times with different configuration. For example, we might want to test the current lldb against inferiors built with different compilers. This configuration was already possible for lldb-dotest, but was lacking for the lit counterpart. It is now possible to pass arguments to pass arguments like this: ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ -Ddotest-args="-foo;-bar" llvm-svn: 333432
* ManualDWARFIndex: Treat DW_TAG_subprogram and DW_TAG_inlined_subroutine the ↵Pavel Labath2018-05-292-1/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | same way Summary: We were treating subprograms and inlined subroutines differently when building the index. The difference was in which indexes were individual tags inserted (subprograms went to all indexes, where as inlined subroutines only into the basename and full name indexes). This seems like an error, because an inlined subroutine can still represent an C++ or an ObjC method. I don't see anything in the subprogram branch which should not apply to an inlined subroutine, so I propose to just treat them identically. This makes searching for an inlined method behave the same way as for the apple index. I write an assembly-based test because I did not want to depend on particular clang inlining behavior (and because I wanted to see how hard would it be). Reviewers: clayborg, JDevlieghere Subscribers: eraman, lldb-commits Differential Revision: https://reviews.llvm.org/D47368 llvm-svn: 333398
* ManualDWARFIndex: Fix misclassification of methods in unionsPavel Labath2018-05-251-0/+31
| | | | | | | Apple index was already treating them as methods. Not doing the same seems like an omission. llvm-svn: 333266
* [lldb-mi] Add possibility to set breakpoints without selecting a target.Adrian Prantl2018-05-244-0/+26
| | | | | | | | | | | Now it's possible to set breakpoints before selecting a target, they will be set to the dummy target and then copied to an each added one. Patch by Alexander Polyakov! Differential Revision: https://reviews.llvm.org/D46588 llvm-svn: 333205
* [SymbolFilePDB] Add a test for wchar_t type in PDB.Aaron Smith2018-05-232-0/+5
| | | | | | | | The wchar_t is unsigned. https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx llvm-svn: 333051
* [SymbolFilePDB] Add support for resolving variable symbolsAaron Smith2018-05-232-0/+108
| | | | | | | | | | | | | | | | | Summary: Implement FindGlobalVariables and ParseVariableContext methods. Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available. This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables. Reviewers: rnk, zturner, lldb-commits Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D45224 llvm-svn: 333049
* Improve coverage of the apple-tables testPavel Labath2018-05-212-4/+30
| | | | | | | | | | | After closer examination, it turns out we mis-classify one of the methods only if two of the structs have the same name. Since this was meant to be a basic test, I rename one of the structs in the test so that we have at least some coverage for the apple tables lookup. Instead, I create an XFAILed test which specifically targets the same-name case (and file a bug to track it). llvm-svn: 332833
* Add some apple-tables lookup testsPavel Labath2018-05-214-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that we are able to parse MachO files everywhere, we can write some cross-platform tests for handling of apple accelerator tables. This reruns the same lookup tests we have for manual indexes on MachO files which will use the accelerator tables instead. This makes sure we return the same results regardless of the method we used to access the debug info. The tests confirm we return the same results for looking up types, namespaces and variables, but have found an inconsistency in the treatment of function lookup. In the function case we mis-classify the method "foo" declared in the local struct sbar (inside function ffbar). We classify it as a function whereas it really is a method. Preliminary analysis suggests this is because DWARFASTParserClang::GetClangDeclContextForDIE returns null when given the local "struct sbar" DIE. This causes us to get the wrong CompilerDeclContext when we ask for the context of the inner foo, which means CompilerDeclContext::ISStructUnionOrClass returns false. Until this is fixed, I do not include the darwin versions of the "base" and "method" function lookup tests. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits Differential Revision: https://reviews.llvm.org/D47064 llvm-svn: 332831
* Make ObjectFileMachO work on non-darwin platformsPavel Labath2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch we were unable to write cross-platform MachO tests because the parsing code did not compile on other platforms. The reason for that was that ObjectFileMachO depended on RegisterContextDarwin_arm(64)? (presumably for core file parsing) and the two Register Context classes uses constants from the system headers (KERN_SUCCESS, KERN_INVALID_ARGUMENT). As far as I can tell, these two files don't actually interact with the darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel process plugin (even though it has "kernel" in the name, this one communicates with it via network packets and not syscalls). For the time being I have created OS-independent definitions of these constants and made the register context classes use those. Long term, the error handling in these classes should be probably changed to use more standard mechanisms such as Status or Error classes. This is the only change necessary (apart from build system glue) to make ObjectFileMachO work on other platforms. To demonstrate that, I remove REQUIRES:darwin from our (only) cross-platform mach-o test. Reviewers: jasonmolenda, aprantl, clayborg, javed.absar Subscribers: mgorny, lldb-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D46934 llvm-svn: 332702
* Retrieve the deployment target when retrieving an object file's triple.Adrian Prantl2018-05-111-0/+205
| | | | | | | | | | | | Getting the deployment target can be significant information when rebuilding clang modules since availability information could depend on it. rdar://problem/40039633 Differential Revision: https://reviews.llvm.org/D46669 llvm-svn: 332067
* [DWARF] Align non-accelerated function fullname searching with the ↵Pavel Labath2018-05-091-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | apple-tables path Summary: Before this patch the two paths were doing very different things - the apple path searched the .apple_names section, which contained mangled names, as well as basenames of all functions. It returned any name it found. - the non-accelerated path looked in the "full name" index we built ourselves, which contained mangled as well as demangled names of all functions (but no basenames). Then however, if it did not find a match it did an extra search in the basename index, with some special handling for anonymous namespaces. This aligns the two paths by changing the non-accelerated path to return the same results as in the apple-tables one. In pratice, this means we will search in both the "basename", "method" and "fullname" indexes (in the manual indexes these are separate indexes. This means the function will return some slightly inappropriate results (e.g. bar::baz::foo when one asks for a "full name" foo), but this can be handled by additional filtering, independently indexing method. I've also stopped inserting demangled names into the "fullname" index, as that is inconsistent with the apple path. Reviewers: clayborg, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46576 llvm-svn: 331855
* Add support to object files for accessing the .debug_types sectionGreg Clayton2018-05-081-2/+16
| | | | | | | | In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch Differential Revision: https://reviews.llvm.org/D46529 llvm-svn: 331777
* [CMake] Unify and relayer testingJonas Devlieghere2018-05-032-19/+13
| | | | | | | | | | | | | | | | | | | | | | | This patch restructures part of LLDB's testing configuration: 1. I moved the test dependencies up the chain so every dotest dependency becomes a lit dependency as well. It wouldn't make sense for dotest to have other dependencies when it's being run by lit. Lit on the other hand can still specify extra dependencies. 2. I replaced as much generator expressions with variables as possible. This is consistent with the rest of LLVM and doesn't break generators that support multiple targets (MSVC, Xcode). This wasn't a problem before, but now we need to expand the dotest arguments in the lit configuration and there's only one test suite even with multiple targets. 3. I moved lldb-dotest into it's own directory under utils since there's no need anymore for it to located under `test/`. Differential revision: https://reviews.llvm.org/D46334 llvm-svn: 331463
* lldb-test symbols: Add ability to do name-based lookupPavel Labath2018-05-039-10/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
* ObjectFileELF: Add support for arbitrarily named code sectionsPavel Labath2018-04-301-0/+14
| | | | | | | | | | | | | | | | | | | ObjectFileELF assumes that code section has ".text" name. There is an exception for kalimba toolchain that can use arbitrary names, but other toolchains also could use arbitrary names for code sections. For example, corert uses separate section for compiled managed code. As lldb doesn't recognize such section it leads to problem with breakpoints on arm, because debugger cannot determine instruction set (arm/thumb) and uses incorrect breakpoint opcode that breaks program execution. This change allows debugger to correctly handle such code sections. We assume that section is a code section if it has SHF_EXECINSTR flag set and has SHT_PROGBITS type. Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>. Differential Revision: https://reviews.llvm.org/D44998 llvm-svn: 331173
* Support reading section ".gnu_debugaltlink"Jan Kratochvil2018-04-293-0/+28
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
* [lit, lldbsuite] Update the lldbsuite to correctly run tests on windows and ↵Aaron Smith2018-04-241-1/+4
| | | | | | | | | | | | | | | | | | | windows server Summary: The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself. In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well. Reviewers: asmith, labath, JDevlieghere, zturner Reviewed By: JDevlieghere, zturner Subscribers: zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D46020 llvm-svn: 330740
* [CMake] Add the missing `dsymutil` dependency when running tests.Davide Italiano2018-04-231-0/+1
| | | | llvm-svn: 330617
* [lit] Generate a single lit cfg file for tests that require dotest.pyJonas Devlieghere2018-04-211-1/+2
| | | | | | | | | | | | | | | | | | The current way that the lit configuration is generated for the LLDB tests that run using dotest causes cmake to fail when using a generator which supports multiple configurations (such as Visual Studio). The failure is because file GENERATE will create a file *per possible configuration* resulting in the same lit configuration file being overwritten multiple times. To fix the issue, we need to create a single lit file that is agnostic of the configurations and can be used for any configuration. Patch by: Stella Stamenova Differential revision: https://reviews.llvm.org/D45918 llvm-svn: 330518
* [LIT] Have lit run the lldb test suiteJonas Devlieghere2018-04-183-0/+121
| | | | | | | | | | | | | | | | | | | | This is the first in what will hopefully become a series of patches to replace the driver logic in dotest.py with LIT. The motivation for this change is that there's no point in maintaining two driver implementations. Since all of the LLVM projects are using lit, this is the obvious choice. Obviously the goal is maintain full compatibility with the functionality offered by dotest. As such we won't be removing anything until that point has been reached. This patch is the initial attempt (referred to as v1) to run the lldb test suite with lit. To do so we introduced a custom LLDB test format that invokes dotest.py with a single test file. Differential revision: https://reviews.llvm.org/D45333 llvm-svn: 330275
* Fix compilation error caused by tgmath.h.Tatyana Krasnukha2018-04-091-1/+1
| | | | | | On CentOS calling functions from <tgmath.h> produces multiple errors "'void*' is not a pointer-to-object type". llvm-svn: 329597
* [ExpressionParser] Re-implement r327356 in a less disruptive way.Davide Italiano2018-03-202-18/+0
| | | | | | | | | | | | Instead of applying the sledgehammer of refusing to insert any C++ symbol in the ASTContext, try to validate the decl if what we have is an operator. There was other code in lldb which was responsible for this, just not really exposed (or used) in this codepath. Also, add a better/more comprehensive test. <rdar://problem/35645893> llvm-svn: 328025
* [Dictionary] Rewrite the test added in r327587 as an inline test.Davide Italiano2018-03-154-20/+0
| | | | | | | | | | | | | | | Until we have a better story for putting commands and check lines in the same file (they're currently ignored), it seems that inline tests are actually more concise and easier to understand. Too bad we have still some python boilerplate, but that's not really substantial so we can live with it. Thanks to Fred for pointing out and Jim for explaining me how to use the inline test format. <rdar://problem/34806516> llvm-svn: 327592
* [DataFormatters] Implement summary for __NSDictionary0.Davide Italiano2018-03-144-0/+20
| | | | | | | | | | | | | | | | | | | Before the patch: (lldb) frame var emptyDictionary (__NSDictionary0 *) emptyDictionary = 0x0000000100304420 After: (lldb) frame var emptyDictionary (__NSDictionary0 *) emptyDictionary = 0x0000000100304420 0 key/value pairs There's nothing much else we can do, as this is always empty by definition. <rdar://problem/34806516> llvm-svn: 327587
* [ExpressionParser] Fix crash when evaluating invalid expresssions.Davide Italiano2018-03-132-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Typical example, illformed comparisons (operator== where LHS and RHS are not compatible). If a symbol matched `operator==` in any of the object files lldb inserted a generic function declaration in the ASTContext on which Sema operates. Maintaining the AST context invariants is fairly tricky and sometimes resulted in crashes inside clang (or assertions hit). The real reason why this feature exists in the first place is that of allowing users to do something like: (lldb) call printf("patatino") even if the debug informations for printf() is not available. Eventually, we might reconsider this feature in its entirety, but for now we can't remove it as it would break a bunch of users. Instead, try to limit it to non-C++ symbols, where getting the invariants right is hopefully easier. Now you can't do in lldb anymore (lldb) call _Zsomethingsomething(1,2,3) but that doesn't seem to be such a big loss. <rdar://problem/35645893> llvm-svn: 327356
* [lit] `llvm-mc` is now a dependency to run tests.Davide Italiano2018-03-121-0/+1
| | | | llvm-svn: 327350
* Re-add change for https://reviews.llvm.org/D42582 with added directories.Jim Ingham2018-03-123-0/+69
| | | | llvm-svn: 327331
* Introduce a setting to disable Spotlight while running the test suiteAdrian Prantl2018-03-122-1/+4
| | | | | | | | | | | This is a more principled approach to disabling Spotlight .dSYM lookups while running the testsuite, most importantly it also works for the LIT-based tests, which I overlooked in my initial fix (renaming the test build dir to lldb-tests.noindex). Differential Revision: https://reviews.llvm.org/D44342 llvm-svn: 327330
* Revert "Improve prologue handling to support functions with multiple entry ↵Vedant Kumar2018-03-121-2/+0
| | | | | | | | | | | | | | | points." This reverts commit r327318. It breaks the Xcode and CMake Darwin builders: clang: error: no such file or directory: '.../source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp' clang: error: no input files More details are in https://reviews.llvm.org/D42582. llvm-svn: 327327
* Improve prologue handling to support functions with multiple entry points.Jim Ingham2018-03-121-0/+2
| | | | | | | | https://reviews.llvm.org/D42582 Patch from Leandro Lupori. llvm-svn: 327318
* [elf] Remove one copy of the section merging codePavel Labath2018-03-091-0/+42
| | | | | | | | | | | | | | | | Summary: Besides being superfluous, this double merging was actually wrong and causing some sections to be added twice. The reason for that was that the code assumes section IDs are unique in the section list, but this is only true if all sections in the list come from the same object file. Reviewers: fjricci, jankratochvil Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D44157 llvm-svn: 327123
* [lldbtestsuite] llvm-objcopy is now required to run the lit tests.Davide Italiano2018-03-071-0/+1
| | | | | | | | | | | There's now a test using llvm-objcopy in lit/. This doesn't fail on the bot(s) because `llvm-objcopy` is probably already available there, but if you get a fresh checkout and run `ninja check-lldb` you'll observe the failure as it's not tracking the dependency correctly. This fixes the problem on my machine, and probably everywhere else. llvm-svn: 326919
* [SymbolFilePDB] Add missing Char16 and Char32 types in a few placesAaron Smith2018-03-072-0/+8
| | | | | | | | | | Reviewers: zturner, rnk, lldb-commits Subscribers: clayborg, llvm-commits Differential Revision: https://reviews.llvm.org/D44166 llvm-svn: 326875
* [SymbolFilePDB] Add support for CVR pointer type qualifierAaron Smith2018-03-072-0/+85
| | | | | | | | | | | | | | | | | Summary: - Complete element type of PDBSymbolTypeArray. - Add a test to check types of multi-dimensional array and pointers with CVR. Reviewers: zturner, rnk, lldb-commits Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44167 llvm-svn: 326859
* [SymbolFilePDB] Get line number for PDBSymbolTypeEnumAaron Smith2018-03-071-6/+6
| | | | | | | | | | | | Reviewers: zturner, lldb-commits, rnk Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44164 llvm-svn: 326858
* Rewrite TestTargetSymbolsBuildidCase to be more focusedPavel Labath2018-03-061-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test was failing in remote debugging scenario with windows as a host as cmd.exe is not able to parse the complicated shell commands in the Makefile. The test seemed like a perfect candidate for a more focused testing approach, so I have rewritten in on top of lldb-test's module-sections functionality. The slight gotcha there was that the Module::GetSectionList does not include the sections from the symbol file until someone manually calls Module::GetSymbolVendor. Normally, this is not an issue, because someone will have initialized the symbol vendor by the time anyone starts looking at the sections. However, when all one this is dump the section list, we run into this problem. I've tried making this behavior more automatic, but it turns out it's not that easy, so for now, I just manually initialize the Symbol Vendor before dumping out the sections in lldb-test. Reviewers: jankratochvil Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D42914 llvm-svn: 326805
* Add "lldb-test breakpoint" command and convert the case-sensitivity test to ↵Pavel Labath2018-02-265-2/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use it Summary: The command takes two input arguments: a module to use as a debug target and a file containing a list of commands. The command will execute each of the breakpoint commands in the file and dump the breakpoint state after each one. The commands are expected to be breakpoint set/remove/etc. commands, but I explicitly allow any lldb command here, so you can do things like change setting which impact breakpoint resolution, etc. There is also a "-persistent" flag, which causes lldb-test to *not* automatically clear the breakpoint list after each command. Right now I don't use it, but the idea behind it was that it could be used to test more complex combinations of breakpoint commands (set+modify, set+disable, etc.). Right now the command prints out only the basic breakpoint state, but more information can be easily added there. To enable easy matching of the "at least one breakpoint location found" state, the command explicitly prints out the string "At least one breakpoint location.". To enable testing of breakpoints set with an absolute paths, I add the ability to perform rudimentary substitutions on the commands: right now the string %p is replaced by the directory which contains the command file (so, under normal circumstances, this will perform the same substitution as lit would do for %p). I use this command to rewrite the TestBreakpointCaseSensitivity test -- the test was checking about a dozen breakpoint commands, but it was launching a new process for each one, so it took about 90 seconds to run. The new test takes about 0.3 seconds for me, which is approximately a 300x speedup. Reviewers: davide, zturner, jingham Subscribers: luporl, lldb-commits Differential Revision: https://reviews.llvm.org/D43686 llvm-svn: 326112
* remove FreeBSD xfail from lit TestCallStdStringFunctionEd Maste2018-02-231-3/+0
| | | | | | | | | | | | | This test is consistently reporting unexpected pass for me, and the expectedFailure decorator was removed from the legacy test in r310626. Apply the same change to the lit version of this test. Will investigate further if this fails once the new buildbot is running tests. llvm.org/pr17807 llvm-svn: 325856
* [testsuite] Run lit tests as part of `check-lldb`.Davide Italiano2018-02-211-0/+1
| | | | | | | | | | Also, fix a missing dependency, as lit requires llvm-config to run. This is becoming more and more important as we write more FileCheck style tests. Differential Revision: https://reviews.llvm.org/D43591 llvm-svn: 325719
* [lit] Update how clang and other binaries are found in per-configuration ↵Aaron Smith2018-02-212-9/+26
| | | | | | | | | | | | | | | | | | | | | | | directories Summary: This is modeled after the clang and llvm lit tests. Several properties have CMAKE_CFG_INTDIR as part of the path - this works correctly when the cmake generator only supports one configuration which is known at configuration time, but it does not work correctly when the cmake generator supports multiple configurations (for example, VS). For VS, CMAKE_CFG_INTDIR ends up set as $Configuration and then it is never updated correctly. Instead, the lit configuration can use a property that can be overwritten at run time. AddLLVM does that for several properties (such as LLVM_TOOLS_DIR). This change is also removing properties from the lit/CMakeLists.txt that are actually set during the call to configure_lit_site_cfg Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: llvm-commits, labath, stella.stamenova, mgorny, hintonda Differential Revision: https://reviews.llvm.org/D43096 llvm-svn: 325652
* Handle typeof() expressionsJonas Devlieghere2018-02-201-0/+13
| | | | | | | | | | | | | | | | | | | | Before this patch, LLDB was not able to evaluate expressions that resulted in a value with a typeof- or decltype-type. This patch fixes that. Before: (lldb) p int i; __typeof__(i) j = 1; j (typeof (i)) $0 = After: (lldb) p int i; __typeof__(i) j = 1; j (typeof (i)) $0 = 1 Differential revision: https://reviews.llvm.org/D43471 rdar://37461520 llvm-svn: 325568
* [SymbolFilePDB] Add support for function symbolsAaron Smith2018-02-094-1/+123
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is combination of following changes, - Resolve function symbols in PDB symbol file. `lldb-test symbols` will display information about function symbols. - Implement SymbolFilePDB::FindFunctions methods. On lldb console, searching function symbol by name and by regular expression are both available. - Create lldb type for PDBSymbolFunc. - Add tests to check whether functions with the same name but from different sources can be resolved correctly. Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: amccarth, labath, llvm-commits Differential Revision: https://reviews.llvm.org/D42443 llvm-svn: 324707
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-233-0/+140
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it Summary: - Fix a null array access bug. This happens when creating the lldb type for a function that has no argument. - Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target. - Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin - The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type. - Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue. - Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's. - There is no line information about typedef, enum etc in a PDB and the source and line information for them are not shown. - There is no information about scoped enumeration. The compiler type is represented as an unscoped one. Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D42434 llvm-svn: 323255
* Revert "[SymbolFilePDB] Fix null array access when parsing the type of a ↵Pavel Labath2018-01-223-140/+0
| | | | | | | | | | function without any arguments, i.e. 'int main()' and add support to test it" This reverts commit r322995, as it breaks lldb-Unit::SymbolFilePDBTests.TestTypedefs <http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715>. llvm-svn: 323102
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-193-0/+140
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it Summary: - Fix a null array access bug. This happens when creating the lldb type for a function that has no argument. - Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target. - Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin - The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type. - Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue. - Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's. - There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown. - There is no information about scoped enumeration. The compiler type is represented as an unscoped one. Reviewers: zturner, lldb-commits, davide, asmith Reviewed By: zturner, asmith Subscribers: llvm-commits, davide Differential Revision: https://reviews.llvm.org/D41427 llvm-svn: 322995
OpenPOWER on IntegriCloud