summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lang
Commit message (Collapse)AuthorAgeFilesLines
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-259-19/+58
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these tests, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314132
* Revert "Initial patchset to get the testsuite running against armv7 and ↵Chris Bieneman2017-09-259-57/+19
| | | | | | | | | | | | | arm64 iOS devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures." This patch has been causing LLDB test failures on ObjC tests. A test log may still be available here: http://lab.llvm.org:8080/green/view/LLDB/job/lldb/1650/ This reverts commit r314038. llvm-svn: 314122
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-229-19/+57
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314038
* Revert this patch; I was emailing with Eugene and they have some other ↵Jason Molenda2017-09-219-57/+19
| | | | | | | | | changes going in today and don't want the two changes to confuse the situation with the build bots. I'll commit tomorrow once they're known good. llvm-svn: 313934
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-219-19/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. There will be some smaller follow-on patches. The changes to tools/lldb-server are verbose and I'm not thrilled with having to skip all of these tests manually. There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64" means it's an ios device, and I need to review & clean these up with an OS check as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't cause problems, but it's not an assumption I want to rely on). I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 313932
* remove FreeBSD xfail decorator from TestCppNsImportEd Maste2017-08-101-1/+0
| | | | | | | | | | The Linux xfail decorator was removed in r272326 with the claim that the test "runs reliably on the linux x86 buildbot." It also runs reliably on FreeBSD for me. llvm.org/pr25925 llvm-svn: 310644
* RFix PR33875 by distinguishing between DWO and clang modules.Adrian Prantl2017-07-241-2/+0
| | | | | | | | This reapplies https://reviews.llvm.org/D35740 with a tweak to find the section by name rather than type. Section types don't distinguish between regular sections and their DWO counterparts. llvm-svn: 308905
* Revert "Fix PR33875 by distinguishing between DWO and clang modules"Adrian Prantl2017-07-231-0/+2
| | | | | | This reverts commit r308850. llvm-svn: 308851
* Fix PR33875 by distinguishing between DWO and clang modulesAdrian Prantl2017-07-231-2/+0
| | | | | | | | | | | | | | The DWO handling code can get confused by clang modules which also use skeleton CUs to point to the object file with the full debug info. This patch detects whether an object is a "real" DWO or a clang module and prevents LLDB from interpreting clang modules as DWO. This fixes the regression in TestWithModuleDebugging. http://llvm.org/bugs/show_bug.cgi?id=33875 Differential Revision: https://reviews.llvm.org/D35740 llvm-svn: 308850
* XFail TestWithModuleDebugging on linux (bug 33875)Pavel Labath2017-07-211-0/+2
| | | | llvm-svn: 308732
* Disable TestGoASTContextPavel Labath2017-07-071-0/+1
| | | | | | | it fails with go 1.8 and we don't seem to have a maintainer of that functionality. llvm-svn: 307391
* Updated the NSArray and NSDictionary formatters to support new storage formats.Sean Callanan2017-06-231-4/+0
| | | | | | | | Also un-xfailed a testcase that was affected by this. Thanks to Jason Molenda for the patch. <rdar://problem/32827216> llvm-svn: 306180
* [testsuite] xfailed two tests that depend on NSString conforming to NSCopying.Sean Callanan2017-06-141-0/+4
| | | | | | | | | | | | | NSString is loaded from the DWARF, which doesn't have the concept of protocols. When this is used with the NSMutableDictionary type from Objective-C modules, this produces errors of the form error: cannot initialize a parameter of type 'id<NSCopying> _Nonnull' with an rvalue of type 'NSString *' We're aware of these problems and have an internal bug report filed (<rdar://problem/32777981>) llvm-svn: 305424
* [LLDB][MIPS] Fix TestRegisterVariables.py.Nitesh Jain2017-06-141-1/+1
| | | | | | | | | Clang does not accept regparm attribute on these platforms. Fortunately, the default calling convention passes arguments in registers any way Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 305378
* [TypeSystem] Handle Clang AttributedTypesSean Callanan2017-06-021-10/+121
| | | | | | | | | | | | | | | | | | | When parsing types originating in modules, it is possible to encounter AttributedTypes (such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext methods deal with them; others do not. In particular, one function that did not was GetTypeInfo, causing TestObjCNewSyntax to fail. This fixes that, treating AttributedType as essentially transparent and getting the information for the modified type. In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of different things, all of which can break independently of one another. I broke it apart into smaller tests so that we get more precise failures when something (like this) breaks. Differential Revision: https://reviews.llvm.org/D33812 llvm-svn: 304510
* Added a testcase for local/namespaced name conflicts.Sean Callanan2017-05-313-0/+39
| | | | | | | | | This works on SVN but is a bit fragile on the Swift branch. I'm adding the test to both, so we have this path covered. <rdar://problem/32372372> llvm-svn: 304314
* Make TestConflictingSymbol run on non-darwin targetsPavel Labath2017-05-171-7/+11
| | | | | | | | | | | For remote targets we need to call registerSharedLibrariesWithTarget to make sure they are installed alongside main executable. This also required a small fixup in the the mentioned function as in this case "One" was both a directory name and a library name template. I fixed it to make sure it checks that the string refers to a file before it assumed it was a full library path. llvm-svn: 303248
* [Expression parser] Look up module symbols before hunting globallySean Callanan2017-05-1611-0/+161
| | | | | | | | | | | | | | | | | | | When it resolves symbol-only variables, the expression parser currently looks only in the global module list. It should prefer the current module. I've fixed that behavior by making it search the current module first, and only search globally if it finds nothing. I've also added a test case. After review, I moved the core of the lookup algorithm into SymbolContext for use by other code that needs it. Thanks to Greg Clayton and Pavel Labath for their help. Differential Revision: https://reviews.llvm.org/D33083 llvm-svn: 303223
* [TypeSystem] Fix inspection of Objective-C object typesSean Callanan2017-05-153-0/+94
| | | | | | | | | | | | | | ptr_refs exposed a problem in ClangASTContext's implementation: it uses an accessor to downcast a QualType to an ObjCObjectPointerType, but the accessor is not fully general. getAs() is the safer way to go. I've added a test case that uses ptr_refs in a way that would crash before the fix. <rdar://problem/31363513> llvm-svn: 303110
* xfail TestClassTemplateParameterPack on gcc to mollify ↵Sean Callanan2017-05-111-1/+3
| | | | | | lldb-x86_64-ubuntu-14.04-cmake. llvm-svn: 302850
* [DWARF parser] Produce correct template parameter packsSean Callanan2017-05-116-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Templates can end in parameter packs, like this template <class T...> struct MyStruct { /*...*/ }; LLDB does not currently support these parameter packs; it does not emit them into the template argument list at all. This causes problems when you specialize, e.g.: template <> struct MyStruct<int> { /*...*/ }; template <> struct MyStruct<int, int> : MyStruct<int> { /*...*/ }; LLDB generates two template specializations, each with no template arguments, and then when they are imported by the ASTImporter into a parser's AST context we get a single specialization that inherits from itself, causing Clang's record layout mechanism to smash its stack. This patch fixes the problem for classes and adds tests. The tests for functions fail because Clang's ASTImporter can't import them at the moment, so I've xfailed that test. Differential Revision: https://reviews.llvm.org/D33025 llvm-svn: 302833
* Windows fix for TestConflictingDefinition makefilePavel Labath2017-05-031-1/+1
| | | | | | | | | | gnuwin32 rm does not like wildcards that match nothing even if we specify -f (probably because the wildcard expansion happens in-process there). We could use make $(wildcard) here, but it seems safer to explicitly list the files here, just like the normal Makefile.rules does. llvm-svn: 302013
* Fixed a bug where we did not properly use the complete versions of ↵Sean Callanan2017-05-039-0/+134
| | | | | | | | | | Objective-C classes. Also added a test case, thanks to Greg Clayton. <rdar://problem/18913551> llvm-svn: 301993
* Provide a mechanism to do some pre-loading of symbols up front.Jim Ingham2017-04-281-4/+17
| | | | | | | | | | | Loading a shared library can require a large amount of work; rather than do that serially for each library, this patch will allow parallelization of the symbols and debug info name indexes. From scott.smith@purestorage.com https://reviews.llvm.org/D32598 llvm-svn: 301609
* Name the C++ source files for two tests correctly.Sean Callanan2017-04-242-2/+2
| | | | llvm-svn: 301280
* Fixed two bad Makefiles that might be breaking Linux.Sean Callanan2017-04-242-2/+2
| | | | llvm-svn: 301277
* [Expression parser] Return both types and variablesSean Callanan2017-04-247-2/+98
| | | | | | | | | | | | | | | | | | | | | Many times a user wants to access a type when there's a variable of the same name, or a variable when there's a type of the same name. Depending on the precise context, currently the expression parser can fail to resolve one or the other. This is because ClangExpressionDeclMap has logic to limit the amount of information it searches, and that logic sometimes cuts down the search prematurely. This patch removes some of those early exits. In that sense, this patch trades performance (early exit is faster) for correctness. I've also included two new test cases showing examples of this behavior – as well as modifying an existing test case that gets it wrong. llvm-svn: 301273
* [DWARF] Fix lookup in the abstract origins of inlined blocks/functionsSean Callanan2017-04-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB uses clang::DeclContexts for lookups, and variables get put into the DeclContext for their abstract origin. (The abstract origin is a DWARF pointer that indicates the unique definition of inlined code.) When the expression parser is looking for variables, it locates the DeclContext for the current context. This needs to be done carefully, though, e.g.: __attribute__ ((always_inline)) void f(int a) { { int b = a * 2; } } void g() { f(3); } Here, if we're stopped in the inlined copy of f, we have to find the DeclContext corresponding to the definition of f – its abstract origin. Clang doesn't allow multiple functions with the same name and arguments to exist. It also means that any variables we see must be placed in the appropriate DeclContext. [Bug 1]: When stopped in an inline block, the function GetDeclContextDIEContainingDIE for that block doesn't properly construct a DeclContext for the abstract origin for inlined subroutines. That means we get duplicated function DeclContexts, but function arguments only get put in the abstract origin's DeclContext, and as a result when we try to look for them in nested contexts they aren't found. [Bug 2]: When stopped in an inline block, the DWARF (for space reasons) doesn't explicitly point to the abstract origin for that block. This means that the function GetClangDeclContextForDIE returns a different DeclContext for each place the block is inlined. However, any variables defined in the block have abstract origins, so they will only get placed in the DeclContext for their abstract origin. In this fix, I've introduced a test covering both of these issues, and fixed them. Bug 1 could be resolved simply by making sure we look up the abstract origin for inlined functions when looking up their DeclContexts on behalf of nested blocks. For Bug 2, I've implemented an algorithm that makes the DeclContext for a block be the containing DeclContext for the closest entity we would find during lookup that has an abstract origin pointer. That means that in the following situation: { // block 1 int a; { // block 2 int b; } } if we looked up the DeclContext for block 2, we'd find the block containing the abstract origin of b, and lookup would proceed correctly because we'd see b and a. However, in the situation { // block 1 int a; { // block 2 } } since there isn't anything to look up in block 2, we can't determine its abstract origin (and there is no such pointer in the DWARF for blocks). However, we can walk up the parent chain and find a, and its abstract origin lives in the abstract origin of block 1. So we simply say that the DeclContext for block 2 is the same as the DeclContext for block 1, which contains a. Lookups will return the same results. Thanks to Jim Ingham for review and suggestions. Differential revision: https://reviews.llvm.org/D32375 llvm-svn: 301263
* Update two android XFAILSPavel Labath2017-04-241-1/+1
| | | | | | | - XFAIL on TestNoreturnUnwind on all architectures - TestStaticVariables fails with clang-3.8 as well llvm-svn: 301186
* Make TestStaticVariables XFAIL more specificPavel Labath2017-04-201-6/+5
| | | | | | | | The test fails because an older clang did not emit the required debug info (I am not sure when this got added, but clang-3.7 certainly did not work yet). The actual platform has nothing to do with this. llvm-svn: 300834
* Fix TestRegisterVariables for clang/armPavel Labath2017-04-191-2/+11
| | | | | | | | Clang rejects __attribute__((regparm)) when targetting arm. The default calling convention passes arguments in registers anyway, so we can just remove them in this case. llvm-svn: 300670
* TestStaticVariables still fails on Linux.Jim Ingham2017-04-181-0/+2
| | | | llvm-svn: 300519
* This test is succeeding on macOS with clang.Jim Ingham2017-04-181-6/+1
| | | | llvm-svn: 300517
* Fix TestCppIncompleteTypes for android/clangPavel Labath2017-04-121-2/+2
| | | | | | | LDFLAGS contains some .a files. If it is specified before the relevant object files, undefined symbol errors occur. llvm-svn: 300048
* FindTypes should find "struct TypeName" as well as "TypeName".Jim Ingham2017-03-213-0/+95
| | | | | | | | | | This fixes a bug introduced by r291559. The Module's FindType was passing the original name not the basename in the case where it didn't find any separators. I also added a testcase for this. <rdar://problem/31159173> llvm-svn: 298331
* Fix TestRegisterVariables for linux arm/arm64 gcc ver > 5Omair Javaid2017-01-131-1/+1
| | | | | | | | | We are going to turn off buffer overflow introduced by gcc by turning off FORTIFY_SOURCE. Differential revision: https://reviews.llvm.org/D28666 llvm-svn: 291949
* XFAIL TestRegisterVariables on gcc-4.8-x86_64Pavel Labath2017-01-101-0/+2
| | | | | | | I have previously enabled this test for this configuration. However, it turns out it only passes for gcc-4.9. llvm-svn: 291563
* Fix i386 being able to show member variables correctly by not returning ↵Greg Clayton2016-12-092-4/+5
| | | | | | | | | | empty objective C types from the runtime. We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience. <rdar://problem/24093343> llvm-svn: 289233
* Handle UTF-16 and UTF-32 constant CFStringsSean Callanan2016-12-012-0/+11
| | | | | | | | | | | | | | | We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array error: warning: expression result unused error: The expression could not be prepared to run in the target This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase. https://reviews.llvm.org/D27291 <rdar://problem/13190557> llvm-svn: 288386
* Enable TestBitfields on linux with clangPavel Labath2016-11-241-7/+0
| | | | | | The test has been passing for a while now. llvm-svn: 287884
* Enable TestRegisterVariables for some configurationsPavel Labath2016-11-241-5/+2
| | | | | | It consistently passes for linux-clang-i386, and linux-gcc-x86_64. llvm-svn: 287883
* Mark xfail TestNamespaceDefinitions for arm/aarch64 targetsOmair Javaid2016-11-111-0/+3
| | | | | | | | Fails with all versions of arm/aarch64 gcc available on ubuntu 16.04/14.04. Passes with Linaro GCC version >= 4.8 but fails with >= 5.0. But There are other regressions when we use Linaro GCC. llvm-svn: 286574
* Un-XFail test on Windows. Has been in "unexpected success" mode for a while.Adrian McCarthy2016-11-101-2/+0
| | | | llvm-svn: 286476
* Fix expectation in TestStaticVariables.py after rL286302Tamas Berghammer2016-11-091-1/+1
| | | | | | | | The debug info emitted by clang for static variables improved by rL286302 and it exposed an incorrect test expactation because now LLDB able to displays more data 9thanks to better debug info) then before. llvm-svn: 286360
* Fix an issue where frame variable -s <varname> would not show the scope even ↵Enrico Granata2016-10-261-1/+1
| | | | | | | | though the user asked for it Part of rdar://28434047 llvm-svn: 285226
* remove xfail from TestObjCNewSyntax.py test_expr_gmodules()Todd Fiala2016-10-241-4/+0
| | | | | | | Fixes: rdar://27792848 llvm-svn: 285032
* Added a decorator for the macOS version and switched over testcases that ↵Sean Callanan2016-10-206-13/+6
| | | | | | used platform.release llvm-svn: 284674
* Remove a debug print statement.Jim Ingham2016-10-181-1/+0
| | | | llvm-svn: 284448
* More testsuite xfail markings cleanup.Jim Ingham2016-10-182-3/+2
| | | | llvm-svn: 284446
* This test is no longer failing for gmodules.Jim Ingham2016-10-151-4/+0
| | | | llvm-svn: 284296
OpenPOWER on IntegriCloud