summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite
Commit message (Collapse)AuthorAgeFilesLines
...
* remove FreeBSD xfail decorator from TestCallStdStringFunctionEd Maste2017-08-101-3/+0
| | | | | | | | | | | This test is consistently reporting unexpected pass for me on FreeBSD 10 and 12. It was failing on the old FreeBSD buildbot which has now been retired for some time. Will investigate further if this fails once a new buildbot is configured and running tests. llvm.org/pr17807 llvm-svn: 310626
* remove FreeBSD xfail decorator from TestExitDuringBreakEd Maste2017-08-101-3/+0
| | | | | | | | This test passes for me on FreeBSD 10 and 12(-CURRENT). llvm.org/pr18190 llvm-svn: 310624
* 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-092-0/+74
| | | | | | | | | | | | 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 ProcessAPITestCase.test_get_process_infoVadim Macagon2017-08-021-15/+27
| | | | llvm-svn: 309803
* 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 test_get_process_info pending bot fixesSean Callanan2017-08-011-0/+1
| | | | llvm-svn: 309714
* Expose process instance info via SB APIVadim Macagon2017-08-013-0/+96
| | | | | | | | | | | Summary: Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo, and add SBProcess::GetProcessInfo() to retrieve info like parent ID, group ID, user ID etc. from a live process. Differential Revision: https://reviews.llvm.org/D35881 llvm-svn: 309664
* XFAIL/XFlakey some tests what become very flakey on the Linux buildbotTamas Berghammer2017-07-272-0/+2
| | | | llvm-svn: 309265
* Fix the formatting for help on option value types.Jim Ingham2017-07-271-0/+9
| | | | | | | | Patch by Jessica Han <jessicah@juniper.net> https://reviews.llvm.org/D35525 llvm-svn: 309238
* Skip test_unique_stacks on Darwin, because it doesn't terminate reliably.Sean Callanan2017-07-251-1/+3
| | | | | | rdar://problem/33462362 llvm-svn: 309046
* Extend 'target symbols add' to load symbols from a given moduleEugene Zemtsov2017-07-243-0/+70
| | | | | | | | | | | | | | Now -shlib flag can be provided alongside with names of symbols files: (lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so This is helpful when default matching mechanisms by name and UUID can't find a module, and the user needs to explicitly specify which module the given symbol file belongs to. Differential Revision: https://reviews.llvm.org/D35607 llvm-svn: 308933
* Skip test_lldbmi_var_update on Darwin.Sean Callanan2017-07-241-0/+1
| | | | llvm-svn: 308919
* 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
* 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-133-84/+7
| | | | 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
* 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
* Working through testcases, converting to run_to_source_breakpoint.Jim Ingham2017-07-065-99/+14
| | | | llvm-svn: 307287
* Revert "Android.rules: build x86 tests with -mstackrealign"Pavel Labath2017-07-062-6/+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
* Add a lldbutils routine that gathers up the boiler-plateJim Ingham2017-07-066-116/+58
| | | | | | | | | | to make a target, set a source regex breakpoint, run to the breakpoint and find the thread that hit the breakpoint. Start the process of replacing the boiler plate with this routine. llvm-svn: 307234
* [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
OpenPOWER on IntegriCloud