summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities
Commit message (Collapse)AuthorAgeFilesLines
* Report inferior signals as signals, not exceptions, on FreeBSDEd Maste2017-08-103-13/+4
| | | | | | | | | | | | | | | | | | | | | This is the FreeBSD equivalent of r238549. This serves 2 purposes: * LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/ SIGFPE the way it is suppose to be handled. Prior to this fix these signals will neither create a coredump, nor exit from the debugger or work for signal handling scenario. * eInvalidCrashReason need not report "unknown crash reason" if we have a valid si_signo llvm.org/pr23699 Patch by Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D35223 llvm-svn: 310591
* Fix PlatformPythonTestCase.test_platform_list for the build botsVadim Macagon2017-08-091-6/+12
| | | | llvm-svn: 310488
* Expose active and available platform lists via SBDebugger APIVadim Macagon2017-08-091-0/+70
| | | | | | | | | | | | Summary: The available platform list was previously only accessible via the `platform list` command, this patch makes it possible to access that list via the SBDebugger API. The active platform list has likewise been exposed via the SBDebugger API. Differential Revision: https://reviews.llvm.org/D35760 llvm-svn: 310452
* Add an auto-continue flag to breakpoints & locations.Jim Ingham2017-08-031-1/+30
| | | | | | | | | | | | | | You can get a breakpoint to auto-continue by adding "continue" as a command, but that has the disadvantage that if you hit two breakpoints simultaneously, the continue will force the process to continue, and maybe even forstalling the commands on the other. The auto-continue flag means the breakpoints can negotiate about whether to stop. Writing tests, I wanted to supply some commands when I made the breakpoints, so I also added that ability. llvm-svn: 309969
* Fix a mis-feature with propagation of breakpoint options -> location options.Jim Ingham2017-08-021-7/+101
| | | | | | | | | | | | | | When an option was set at on a location, I was just copying the whole option set to the location, and letting it shadow the breakpoint options. That was wrong since it meant changes to unrelated options on the breakpoint would no longer take on this location. I added a mask of set options and use that for option propagation. I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands since I wanted to use them to write some more test cases. <rdar://problem/24397798> llvm-svn: 309772
* XFAIL/XFlakey some tests what become very flakey on the Linux buildbotTamas Berghammer2017-07-272-0/+2
| | | | llvm-svn: 309265
* Skip test_unique_stacks on Darwin, because it doesn't terminate reliably.Sean Callanan2017-07-251-1/+3
| | | | | | rdar://problem/33462362 llvm-svn: 309046
* Expose hit count via SBBreakpointLocation.Bruce Mitchener2017-07-193-0/+141
| | | | | | | | | | | | | | | Summary: SBBreakpointLocation exposed the ignore count, but didn't expose the hit count. Both values were exposed by SBBreakpoint and SBWatchpoint, so this makes things a bit more consistent. Reviewers: lldb-commits Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31283 llvm-svn: 308480
* Convert a few more tests to use run_to_source_breakpoint.Jim Ingham2017-07-132-58/+5
| | | | llvm-svn: 307943
* Upstreaming a patch from Github: When evaluation user expressions, ignore ↵Kuba Mracek2017-07-133-0/+64
| | | | | | InstrumentationRuntime breakpoints. (#235) llvm-svn: 307881
* NativeProcessLinux: Fix handling of raise(SIGTRAP)Pavel Labath2017-07-112-0/+12
| | | | | | | | | | | | | | | | | | | | | In NativeProcessLinux::MonitorSIGTRAP we were asserting that the si_code value is one of the codes we know about. However, that list was very incomplete -- for example, we were not handling SI_TKILL/SI_USER, generated by raise(SIGTRAP). A cursory examination show there are at least a dozen codes like these that an app can generate, and more can be added at any point. So, instead of trying to play catchup, I change the default behavior to treat an unknown si_code like an ordinary signal. The only reason we needed to inspect si_code in the first place is because watchpoint/breakpoints are notified as SIGTRAP, but we already know about those, and us starting to use a new debug event is far less likely than somebody introducing a new non-debug event. I add a test case to TestRaise to verify we are handling raise(SIGTRAP) in an application properly. llvm-svn: 307644
* Update message that Main Thread Checker produces.Kuba Mracek2017-07-081-2/+2
| | | | llvm-svn: 307464
* Revert "Android.rules: build x86 tests with -mstackrealign"Pavel Labath2017-07-061-2/+0
| | | | | | | | | | | Starting with android ndk r15, clang much more tests are affected by the -mstackrealign bugl (now nearly all functions are affected, and not just the ones requiring 16-byte alignment). Due to their numbers, Xfailing all of them is not a viable option, so we will just have to declare this configuration unsupported, and wait until ndk ships a clang version that has this bug fixed. llvm-svn: 307252
* [lldb] Add a testcase for MainThreadCheckerRuntime pluginKuba Mracek2017-07-053-0/+78
| | | | | | 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-291-12/+2
| | | | | | | | | | | | | 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 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-163-0/+100
| | | | | | MainThreadCheckerRuntime plugins. llvm-svn: 305589
* [LLDB][MIPS] Fix TestNoreturnUnwind.py.Nitesh Jain2017-06-141-0/+1
| | | | | | | bugnumber=llvm.org/pr33452 Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 305380
* 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
* We shouldn't put actual tests in directories that containJim Ingham2017-05-233-1/+1
| | | | | | other test directories. llvm-svn: 303643
* Skip TestWatchedVarHitWhenInScope on android arm because it triggers a ↵Pavel Labath2017-05-161-0/+3
| | | | | | kernel bug llvm-svn: 303160
* 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
* 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
* [LLDB][MIPS] Fix typo in TestStepOverWatchpoint.py.Nitesh Jain2017-04-251-1/+1
| | | | | Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 301295
* 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
* 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
* 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
* Fix !N and !-N commands and add a test case.Jim Ingham2017-04-191-0/+45
| | | | | | <rdar://problem/31713267> llvm-svn: 300785
* Add back code to implement "frame var -a,-l,-g" filters.Jim Ingham2017-04-183-0/+116
| | | | | | | | | | r285226 dropped the code that did these checks. I am pretty sure that was inadvertent, so I added that back in and added a test for it. <rdar://problem/31661252> llvm-svn: 300564
* Add libc++ category to the remaining libc++ data formattersPavel Labath2017-04-126-75/+76
| | | | llvm-svn: 300054
* Fix libc++ vector<bool> data formatter (bug #32553)Pavel Labath2017-04-121-1/+0
| | | | | | | | | | | | | | | | | Summary: The iteration list through the available data formatters was undefined, which meant that the vector<bool> formatter kicked in only in cases where it happened to be queried before the general vector formatter. To fix this, I merge the two data formatter entries into one, and select which implementation to use in the factory function. Reviewers: jasonmolenda, tberghammer, EricWF Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31880 llvm-svn: 300047
* Fix TestGuessLanguage for gccPavel Labath2017-04-121-1/+7
| | | | | | | | gcc emits DW_LANG_C89 even if we specify -std=c99 during compilation. Since this isn't an lldb bug, but just the way the compiler happens to be implemented, I teach the test to expect this situation correctly. llvm-svn: 300046
* Teach SBFrame how to guess its language.Jim Ingham2017-04-127-0/+134
| | | | | | <rdar://problem/31411646> llvm-svn: 300012
* Add missing annotation to TestDataFormatterUnorderedPavel Labath2017-04-111-0/+1
| | | | llvm-svn: 299934
* Mark this test as XFAIL on all platforms, it's happening everywhere.Jason Molenda2017-04-071-1/+1
| | | | | | llvm.org/pr32553 and <rdar://problem/30646077> are tracking this. llvm-svn: 299807
* XFAIL TestDataFormatterLibcxxVBool on Linux & AndroidTamas Berghammer2017-04-061-0/+1
| | | | | | | The skipping logic for the test have been fixed recently but the test is very flakey on the buildbot. llvm-svn: 299677
* Annotate some more libc++ tests with the new categoryPavel Labath2017-04-053-29/+20
| | | | | | This makes sure we are able to run them properly on android. llvm-svn: 299588
* The darwin_log tests are very fragile and currently do not properly assess ↵Sean Callanan2017-04-051-0/+1
| | | | | | | | | | the state of that functionality. I have put them all in their own category, and made that category disabled by default. Differential revision: https://reviews.llvm.org/D31718 llvm-svn: 299587
* Skip three test cases that are asserting on macosx as of r299199. A quickJason Molenda2017-04-043-0/+10
| | | | | | | | | | | | | | | | | | look showed that the target's arch has no core / byte order and so when AuxVector::AuxVector calls into a dataextractor and sets the byte size to 0, it asserts. e.g. m_arch = { m_triple = (Data = "x86_64--linux", Arch = x86_64, SubArch = NoSubArch, Vendor = UnknownVendor, OS = Linux, Environment = UnknownEnvironment, ObjectFormat = ELF) m_core = kCore_invalid m_byte_order = eByteOrderInvalid m_flags = 0x00000000 m_distribution_id = <no value available> } <rdar://problem/31380097> llvm-svn: 299408
* Add support for sythetic operator dereferenceTamas Berghammer2017-03-311-0/+6
| | | | | | | | | | | | | | | | Summary: After this change a sythetic child provider can generate a special child named "$$dereference$$" what if present is used when "operator*" or "operator->" used on a ValueObject. The goal of the change is to make expressions like "up->foo" work inside the "frame variable" command. Reviewers: labath, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31368 llvm-svn: 299251
* Do not dereference std::unique_ptr by defaultTamas Berghammer2017-03-312-5/+47
| | | | | | | | | | | | | | | Summary: Displaying the object pointed by the unique_ptr can cause an infinite recursion when we have a pointer loop so this change stops that behavior. Additionally it makes the unique_ptr act more like a class containing a pointer (what is the underlying truth) instead of some "magic" class. Reviewers: labath, jingham Differential Revision: https://reviews.llvm.org/D31366 llvm-svn: 299249
* [LLDB][MIPS] Fix Core file Architecture and OS information.Nitesh Jain2017-03-317-0/+16
| | | | | | | | | | Reviewers: labath, clayborg Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D31280 llvm-svn: 299199
* Centralize libc++ test skipping logicPavel Labath2017-03-2911-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This aims to replace the different decorators we've had on each libc++ test with a single solution. Each libc++ will be assigned to the "libc++" category and a single central piece of code will decide whether we are actually able to run libc++ test in the given configuration by enabling or disabling the category (while giving the user the opportunity to override this). I started this effort because I wanted to get libc++ tests running on android, and none of the existing decorators worked for this use case: - skipIfGcc - incorrect, we can build libc++ executables on android with gcc (in fact, after this, we can now do it on linux as well) - lldbutil.skip_if_library_missing - this checks whether libc++.so is loaded in the proces, which fails in case of a statically linked libc++ (this makes copying executables to the remote target easier to manage). To make this work I needed to split out the pseudo_barrier code from the force-included file, as libc++'s atomic does not play well with gcc on linux, and this made every test fail, even though we need the code only in the threading tests. So far, I am only annotating one of the tests with this category. If this does not break anything, I'll proceed to update the rest. Reviewers: jingham, zturner, EricWF Subscribers: srhines, lldb-commits Differential Revision: https://reviews.llvm.org/D30984 llvm-svn: 299028
* Delete TestLLVM.pyZachary Turner2017-03-221-67/+0
| | | | | | | | | | | | | This was added to workaround a limitation in LLVM's implementation of getting the current user's home directory, since it would only look at the value of $HOME, but we did not want to rely on that being set so we would also look in the password database. Adding the ability to look in the password database to LLVM was a straightforward patch that was submitted in r298513, so since that is done this test is no longer needed. llvm-svn: 298519
* Get ObjectFileMachO to handle @executable_pathJim Ingham2017-03-205-0/+64
| | | | | | | | | Only do this when we are debugging an executable, since we don't have a good way to trace from an ObjectFile back to its containing executable. Detecting pre-run libs before running is "best effort" in lldb, but this one is pretty easy. llvm-svn: 298290
OpenPOWER on IntegriCloud