summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Add a testcase for MainThreadCheckerRuntime pluginKuba Mracek2017-07-054-0/+92
| | | | | | This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread Checker) is only available on Darwin, so the test also detects the presence of libMainThreadChecker.dylib and is skipped if the tool is not available. llvm-svn: 307170
* Android.rules: build x86 tests with -mstackrealignPavel Labath2017-06-292-12/+6
| | | | | | | | | | | | | All android builds systems have switched to -mstackrealign for building x86 binaries, so follow their cue with our mini build system. This presently breaks just one test (TestReturnValue), and this is due to a compiler bug, which has already been fixed in clang, but it hasn't made it yet into the official NDK compiler. While I'm touching that test, I also remove an android-specific XFAIL, which is not relevant anymore. llvm-svn: 306683
* 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
* Updated NSNumber formatter for new internal representation.Sean Callanan2017-06-191-2/+13
| | | | | | <rdar://problem/32780109> llvm-svn: 305727
* Upstreaming the UndefinedBehaviorSanitizerRuntime and ↵Kuba Mracek2017-06-164-0/+147
| | | | | | MainThreadCheckerRuntime plugins. llvm-svn: 305589
* Change how LocateDSYMInVincinityOfExecutable strips off pathJason Molenda2017-06-1510-0/+298
| | | | | | | | | | | | | | | | | | components to not depend on "." characters in the fileanme (e.g. "Foundation.framework") but instead to just use path separators. The names of the files themselves may have dots in them ("com.apple.sbd") which would break the old scheme. Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename) as well as a test case for r304520 (macosx/find-dsym/deep-bundle) which needed a similar setup to test correctly on a single machine. (both of these are really testing remote debug session situations where the binary can't be found on the system where lldb is running, complicating the test case a bit.) <rdar://problem/31825940> llvm-svn: 305441
* [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] Skip TestGdbRemoteSingleStep and TestGdbRemote_vCont.py.Nitesh Jain2017-06-142-0/+3
| | | | | | | | The step count depends on code generated by compiler (GCC/Clang). It will also vary for different MIPS arch variant. Hence skipping these test for MIPS. Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 305383
* [LLDB][MIPS] Fix TestNoreturnUnwind.py.Nitesh Jain2017-06-141-0/+1
| | | | | | | bugnumber=llvm.org/pr33452 Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 305380
* [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
* Mark TestCallThatRestarts as flaky on androidPavel Labath2017-06-131-0/+2
| | | | | | | | | | | | | This test started being flaky since r303848 (RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false). I am not reverting that, as I am confident that actually fixed a problem. A more likely explanation is that there is still one corner case that is not handled correctly there. Marking the test as flaky until I get a chance to investigate. I also mark the test as no-debug-info-dependend -- it stresses expression evaluation, as far as debug info goes, the test if extremely simple. llvm-svn: 305286
* Introduce new command: thread backtrace uniquePavel Labath2017-06-122-14/+86
| | | | | | | | | | | | | | | | | This patch introduces a new thread backtrace command "unique". The command is based off of "thread backtrace all" but will instead find all threads which share matching call stacks and de-duplicate their output, listing call stack and all the threads which share it. This is especially useful for apps which use thread/task pools sitting around waiting for work and cause excessive duplicate output. I needed this behavior recently when debugging a core with 700+ threads. Differential Revision: https://reviews.llvm.org/D33426 Reviewers: clayborg, jingham Patch by Brian Gianforcaro <b.gianfo@gmail.com> llvm-svn: 305197
* Skip TestNoreturnUnwind on linux+clang+armPavel Labath2017-06-091-0/+2
| | | | | | | | I was over-eager to unable this test in r304976. It still fails in this combination, at there does not seem to be anything we can do about it, as the generated code does not preserve the link register. llvm-svn: 305062
* Fix backtrace of noreturn functions situated at the end of a modulePavel Labath2017-06-086-4/+88
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When a call instruction is the last instruction in a function, the backtrace PC will point past the end of the function. We already had special code to handle that, but we did not handle the case where the PC ends up outside of the bounds of the module containing the function, which is a situation that occured in TestNoreturnUnwind on android for some arch/compiler combinations. I fix this by adding an argument to Address resolution code which states that we are ok with addresses pointing to the end of a module/section to resolve to that module/section. I create a reproducible test case for this situation by hand-crafting an executable which has a noreturn function at the end of a module. Reviewers: jasonmolenda, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32022 llvm-svn: 304976
* [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
* Added new API to SBStructuredData classAbhishek Aggarwal2017-05-291-0/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Added API to access data types -- integer, double, array, string, boolean and dictionary data types -- Earlier user had to parse through the string output to get these values - Added Test cases for API testing - Added new StructuredDataType enum in public include file -- Replaced locally-defined enum in StructuredData.h with this new one -- Modified other internal files using this locally-defined enum Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: clayborg, lldb-commits Reviewed By: clayborg Subscribers: labath Differential Revision: https://reviews.llvm.org/D33434 llvm-svn: 304138
* Recommit "RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false"Pavel Labath2017-05-252-18/+55
| | | | | | | | | | | | | | | | | | This is a resubmit of r303732, which was reverted due to a regression. The original patch caused a regression in TestLoadUnload, which has only showed up when running the remote test suite. The problem there was that we interrupted the target just as it has hit the rendezvous breakpoint in the dlopen call. This meant that the stop reason was set to "breakpoint" even though the event would not have been broadcast if we had not stopped the process. I fix this by checking StopInfo->ShouldNotify() before stopping. I also add a new test for the handling of conditional breakpoints in expressions, which I noticed to be broken (pr33164) Differential Revision: https://reviews.llvm.org/D33283 llvm-svn: 303848
* Revert "RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false"Pavel Labath2017-05-241-14/+6
| | | | | | | This reverts commit r303732, as it introduces a regression in TestLoadUnload on android. llvm-svn: 303740
* RunThreadPlan: Fix halting logic in IgnoreBreakpoints = falsePavel Labath2017-05-241-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The function had logic to handle the case when the expression terminated while we were trying to halt the process, but it failed to take into account the possibility that the expression stopped because it hit a breakpoint. This was caused by the fact that the handling of the stopped events was duplicated for the "halting" and regular cases (the regular case handled this situation correctly). I've tried to merge these two cases into one to make sure they stay in sync. I should call out that the two cases were checking whether the thread plan has completed in slightly different ways. I am not sure what is the difference between them, but I think the check should be the same in both cases, whatever it is, so I just took the one from the regular case, as that is probably more tested. For the test, I modified TestUnwindExpression to run the expression with a smaller timeout (this is how I found this bug originally). With a 1ms one thread timeout, the test failed consistently without this patch. Reviewers: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D33283 llvm-svn: 303732
* We shouldn't put actual tests in directories that containJim Ingham2017-05-233-1/+1
| | | | | | other test directories. llvm-svn: 303643
* Don't override the SDKs and force the use of /System/Library/Frameworks toJason Molenda2017-05-191-1/+1
| | | | | | | find the python headers when buiding crashinfo.c <rdar://problem/32288076> llvm-svn: 303465
* Make TestConflictingSymbol run on non-darwin targetsPavel Labath2017-05-172-8/+12
| | | | | | | | | | | 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
* Skip TestWatchedVarHitWhenInScope on android arm because it triggers a ↵Pavel Labath2017-05-161-0/+3
| | | | | | kernel bug llvm-svn: 303160
* [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
* Disable a test in TestReturnValue on arm64 linuxPavel Labath2017-05-151-1/+6
| | | | | | | | | | as described in pr33042, we cannot reliably retrieve the return value on arm64 in cases it is returned via x8 pointer. I tried to do this as surgically as possible and disabled it only on targets I know to be affected, as the code is still useful, even though it can only work on best-effort basis. llvm-svn: 303076
* 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
* Add missing 'arch' key to valid qHostInfo keysFrancis Ricci2017-05-051-0/+1
| | | | | | | | | | | | | | Summary: 'arch' is a valid qHostInfo key, but the unit test for qHostInfo did not include it in the set of possible keys. Reviewers: tfiala, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32711 llvm-svn: 302260
* Fix segfault resulting from empty print promptPavel Labath2017-05-051-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I have found a way to segfault lldb in 7 keystrokes! Steps to reproduce: 1) Launch lldb 2) Type `print` and hit enter. lldb will now prompt you to type a list of expressions, followed by an empty line. 3) Hit enter, indicating the end of your input. 4) Segfault! After some investigation, I've found the issue in Host/common/Editline.cpp. Editline::MoveCursor() relies on m_input_lines not being empty when the `to` argument is CursorPosition::BlockEnd. This scenario, as far as I can tell, occurs in one specific instance: In Editline::EndOrAddLineCommand() when the list of lines being processed contains exactly one string (""). Meeting this condition is fairly simple, I have posted steps to reproduce above. Reviewers: krytarowski, zturner, labath Reviewed By: labath Subscribers: scott.smith, lldb-commits Differential Revision: https://reviews.llvm.org/D32421 Patch by Alex Langford. llvm-svn: 302225
* ABISysV_arm64: compute return value for large vectors correctlyPavel Labath2017-05-051-11/+39
| | | | | | | | | | | | | | | | | | | | | Summary: Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes are stored in v0 (which makes sense, as that's the size of the register). 32-byte vector types are passed as regular structs via x8 pointer. Treat them as such. This fixes TestReturnValue for arm64-clang. I also split the test case into two so I can avoid the if(gcc) line, and annotate each test instead. (It seems the vector type tests fail with gcc only when targetting x86 arches). Reviewers: tberghammer, eugene Subscribers: aemerson, omjavaid, rengolin, srhines, lldb-commits Differential Revision: https://reviews.llvm.org/D32813 llvm-svn: 302220
* [LLDB][MIPS] Fix TestStepOverBreakpoint.py failure.Nitesh Jain2017-05-041-5/+4
| | | | | | | | | | Reviewers: jingham, labath Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D32168 llvm-svn: 302139
* Don't attempt to use mpx registers on unsupported platformsFrancis Ricci2017-05-032-0/+10
| | | | | | | | | | | | | | Summary: The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient, as this isn't defined for linux kernel versions below 3.19. Reviewers: valentinagiusti, zturner, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32719 llvm-svn: 302027
* 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
* Android.rules: set "ar" path correctlyPavel Labath2017-05-021-0/+1
| | | | llvm-svn: 301918
* 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
* [LLDB][MIPS] Forgot to add check in commit rl301530Nitesh Jain2017-04-271-2/+4
| | | | | | | Reviewers: ki.stfu, labath Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 301537
* [LLDB][MIPS] Fix TestMiExec.py failure.Nitesh Jain2017-04-271-2/+8
| | | | | | | | | | Reviewers: ki.stfu, labath Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D32340 llvm-svn: 301530
* [LLDB][MIPS] Fix typo in TestStepOverWatchpoint.py.Nitesh Jain2017-04-251-1/+1
| | | | | Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 301295
* 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-242-2/+2
| | | | | | | - XFAIL on TestNoreturnUnwind on all architectures - TestStaticVariables fails with clang-3.8 as well llvm-svn: 301186
* Skip TestLibCxxAtomic with gccPavel Labath2017-04-201-0/+1
| | | | | | | older versions of libc++ (still used on some linux systems) are not compatible with gcc. llvm-svn: 300837
* Recompute ArchSpec core after MergeFromPavel Labath2017-04-203-10/+0
| | | | | | | | | | | | | | | | | | Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
* 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
* Add libc++ category the three more testsPavel Labath2017-04-203-48/+103
| | | | | | | | I thought my previous commit got the last ones but somehow I missed these. This also resurrects TestDataFormatterLibcxxSet, which got commented out in r263859 as a part of some seemingly unrelated change. llvm-svn: 300833
OpenPOWER on IntegriCloud