summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fix TestMoveNearest for remote targetsPavel Labath2017-03-151-1/+2
| | | | | | | Launching a process with shared libraries on remote targets requires a special dance, which I forgot to do in r297830. llvm-svn: 297834
* Fix TestMoveNearest breakage on darwinPavel Labath2017-03-151-0/+4
| | | | | | | | | It seems that on darwin we are not able to resolve breakpoints in the test shared library until the process has started. That seems unfortunate, but it is not the purpose of this test, so work around that by starting the process before doing the rest of our checks. llvm-svn: 297830
* BreakpointResolverFileLine: Restrict move-to-nearest-code from moving across ↵Pavel Labath2017-03-157-15/+85
| | | | | | | | | | | | | | | | | | | | | | | | | function boundaries Summary: This fixes the case where a user tries to set a breakpoint on a source line outside of any function (e.g. because that code is #ifdefed out, or the compiler did not emit code for the function, etc.) and we would silently move the breakpoint to the next function. Now we check whether the line range of the resolved symbol context function matches the original line number. We reject any breakpoint locations that appear to move the breakpoint into a new function. This filtering only happens if we have full debug info available (e.g. in case of -gline-tables-only compilation, we still set the breakpoint on the nearest source line). Reviewers: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30817 llvm-svn: 297817
* Add a test to ensure that SBFrame::Disassemble produces some output.Jim Ingham2017-03-012-1/+69
| | | | llvm-svn: 296692
* Mark TestYMMRegister as no_debug_info_testPavel Labath2017-03-011-0/+1
| | | | | | | We don't need to run this test multiple times to check whether we can read a register. llvm-svn: 296611
* Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint objectPavel Labath2017-02-271-1/+0
| | | | | | | | | | | | | | | | | Summary: There is nothing we can do with the breakpoint once the associated target becomes deleted. This will make sure we don't hold on to more resources than we need in this case. In particular, this fixes the case TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object causes us to nor unmap the executable file from memory. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30249 llvm-svn: 296328
* Hardware breakpoints for Linux on Arm/AArch64 targetsOmair Javaid2017-02-243-0/+171
| | | | | | | | Please look at below differential link for upstream discussion. Differential revision: https://reviews.llvm.org/D29669 llvm-svn: 296119
* Switch "posix" to the new log channel registration mechanismPavel Labath2017-02-231-11/+5
| | | | | | | | | | | | | | | | | | Summary: This also removes magic rename code, which caused the channel to be called "linux" when built on a linux machine, and "freebsd" when built on a freebsd one, which seems unnecessary - registering a new channel is sufficiently simple now that if we wish to log something extremely os-specific, we can just create a new channel. None of the current categories seem very specific to one OS or another. Reviewers: emaste, krytarowski Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30250 llvm-svn: 295954
* Mark TestDarwinLogBasic.py as an xfail because the logging isJason Molenda2017-02-221-0/+1
| | | | | | | not being picked up; filed <rdar://problem/30645203> to track the work to investigate this. llvm-svn: 295804
* Skip TestStepOverBreakpoint on windowsPavel Labath2017-02-151-0/+2
| | | | llvm-svn: 295211
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-02-153-0/+140
| | | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) https://reviews.llvm.org/D29909 (fix for TestCallThatThrows test fail) llvm-svn: 295168
* [LLDB][MIPS] Fix TestMiniDumpNewNitesh Jain2017-02-081-0/+8
| | | | | | | | | | Reviewers: labath, clayborg Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D29215 llvm-svn: 294415
* Move the stop point to somewhere before the final use of theJim Ingham2017-01-311-1/+2
| | | | | | variable we are inspecting. llvm-svn: 293666
* Unroll r292930 due to TestCallThatThrows test fail is not fixed in ↵Boris Ulasevich2017-01-273-140/+0
| | | | | | reasonable time. llvm-svn: 293269
* Jim unintentionally had the gdb-format specifiers falling throughJason Molenda2017-01-252-0/+19
| | | | | | | | | after r276132 so that 'x/4b' would print out a series of 4 8-byte quantities. Fix that, add a test case. <rdar://problem/29930833> llvm-svn: 293002
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-01-243-0/+140
| | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) llvm-svn: 292930
* Fix-up TestLinuxCore for r290874Pavel Labath2017-01-031-0/+8
| | | | | | | | | | | | r290874 enabled the s390x test, which caused the rest of the tests to start misbehaving. This is because this test switches the selected platform and the change persists. This fixes it by explicitly resetting the platform in a similar way to the gcore tests do. Potentially we should consider re-setting the platform globally between each test run to better protect tests from each other. llvm-svn: 290890
* Simplify reading of Linux notes to correctly handle endianess.Howard Hellyer2017-01-031-3/+1
| | | | | | | | | | | | | | | Summary: This patch changes and simplifies the way notes are read from Linux Elf cores. The current implementation copies the bytes from the notes directly over the lldb structure for 64 bit cores and reads field by field for 32 bit cores. Reading the bytes directly only works if the endianess of the core dump and the platform that lldb are running on matches. The case statements for s390x and x86_64 would would only work on big endian systems and little endian systems respectively. That meant that x86_64 generally worked but s390x didn't unless you were on s390x or another big endian platform. This patch just reads field by field on all platform and updates the field by field version to allow for those fields which are word size instead of fixed size. It should also slightly simplify adding support for a new Linux platform. This patch also re-enables the s390x test case in TestLinuxCore.py on all non-s390x platforms as it now passes. Reviewers: uweigand, clayborg Differential Revision: https://reviews.llvm.org/D27571 llvm-svn: 290874
* XFail TestNoreturnUnwind for arm targetsOmair Javaid2017-01-021-0/+1
| | | | | | | | TestNoreturnUnwind fails on arm/aarch32 linux targets. Bug is already described for x86_64 android targets in llvm.org/pr31192. llvm-svn: 290821
* Rollback my commit r290168 to fix linux tests failure. I'll be back!Boris Ulasevich2016-12-203-140/+0
| | | | llvm-svn: 290197
* Bug 30863 - Step doesn't stop with coditional breakpoint on the next lineBoris Ulasevich2016-12-203-0/+140
| | | | | | | | | Fixed by additional completed plans detection, and applying them on breakpoint condition fail. Thread::GetStopInfo reworked. New test added. Review https://reviews.llvm.org/D26497 Many thanks to Jim llvm-svn: 290168
* Test num locations >= 1 not == 1.Jim Ingham2016-12-141-1/+1
| | | | llvm-svn: 289695
* [LLDB][MIPS] Fix TestMultipleHits for MIPSNitesh Jain2016-12-091-2/+2
| | | | | | | | | | Reviewers: clayborg, labath, zturner Subscribers: jaydeep, bhushan, slthakur, lldb-commits Differential Revision: https://reviews.llvm.org/D27085 llvm-svn: 289210
* Update test expectations after AddressSanitizer text descriptions changed in ↵Kuba Mracek2016-12-022-2/+2
| | | | | | r288535. llvm-svn: 288542
* PR31214: Make a test tolerate "line 0" when stepping by instruction.Paul Robinson2016-11-301-4/+10
| | | | | | Differential Revision: http://reviews.llvm.org/D27282 llvm-svn: 288282
* XFAIL: TestNoreturnUnwind on android x86_64Pavel Labath2016-11-281-0/+1
| | | | llvm-svn: 288032
* Enable WatchpointPythonCommandTestCase-test_continue_in_watchpoint_commandPavel Labath2016-11-241-2/+0
| | | | | | | | This test passes consistently on linux, so I am removing the overall XFAIL. If it fails on your configuration, please put a targeted xfail instead (i'll add them my self if I get any breakage emails). llvm-svn: 287881
* Patch for lldb bug 26322 “core load hangs”Howard Hellyer2016-11-244-0/+0
| | | | | | Correct 0 byte core files uploaded by arc. llvm-svn: 287861
* Patch for lldb bug 26322 “core load hangs”Howard Hellyer2016-11-2412-0/+369
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch changes the way ProcessElfCore.cpp handles signal information. The patch changes ProcessElfCore.cpp to use the signal from si_signo in SIGINFO notes in preference to the value of cursig in PRSTATUS notes. The value from SIGINFO seems to be more thread specific. The value from PRSTATUS is usually the same for all threads even if only one thread received a signal. If it cannot find any SIGINFO blocks it reverts to the old behaviour and uses the value from cursig in PRSTATUS. If after that no thread appears to have been stopped it forces the status of the first thread to be SIGSTOP to prevent lldb hanging waiting for any thread from the core file to change state. The order is: - If one or more threads have a non-zero si_signo in SIGINFO that will be used. - If no threads had a SIGINFO block with a non-zero si_signo set all threads signals to the value in cursig in their PRSTATUS notes. - If no thread has a signal set to a non-zero value set the signal for only the first thread to SIGSTOP. This resolves two issues. The first was identified in bug 26322, the second became apparent while investigating this problem and looking at the signal values reported for each thread via “thread list”. Firstly lldb is able to load core dumps generated by gcore where each thread has a SIGINFO note containing a signal number but cursig in the PRSTATUS block for each thread is 0. Secondly if a SIGINFO note was found the “thread list” command will no longer show the same signal number for all threads. At the moment if a process crashes, for example with SIGILL, all threads will show “stop reason = signal SIGILL”. With this patch only the thread that executed the illegal instruction shows that stop reason. The other threads show “stop reason = signal 0”. Reviewers: jingham, clayborg Subscribers: sas, labath, lldb-commits Differential Revision: https://reviews.llvm.org/D26676 llvm-svn: 287858
* ELF core: Adding parsing of the floating-point and SSE registers on x86 ↵Dimitar Vlahovski2016-11-204-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 32/64 bit elf core files Summary: The floating-point and SSE registers could be present in the elf-core file in the note NT_FPREGSET for 64 bit ones, and in the note NT_PRXFPREG for 32 bit ones. The entire note is a binary blob matching the layout of the x87 save area that gets generated by the FXSAVE instruction (see Intel developers manual for more information). This CL mainly modifies the RegisterRead function in RegisterContextPOSIXCore_x86_64 for it to return the correct data both for GPR and FPR/SSE registers, and return false (meaning "this register is not available") for other registers. I added a test to TestElfCore.py that tests reading FPR/SSE registers both from a 32 and 64 bit elf-core file and I have inluded the source which I used to generate the core files. I tried to also add support for the AVX registers, because this info could also be present in the elf-core file (note NT_X86_XSTATE - that is the result of the newer XSAVE instruction). Parsing the contents from the file is easy. The problem is that the ymm registers are split into two halves and they are in different places in the note. For making this work one would either make a "hacky" approach, because there won't be any other way with the current state of the register contexts - they assume that "this register is of size N and at offset M" and don't have the notion of discontinuos registers. Reviewers: labath Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D26300 llvm-svn: 287506
* Fix "thread step until" handling of multiple line inputs.Jim Ingham2016-11-183-0/+117
| | | | | | Also document that it handles same, and add some tests. llvm-svn: 287386
* Fix TestMiniDumpNew.py test for Python 2/3 issueAdrian McCarthy2016-11-141-3/+4
| | | | | | | | On Windows, where we use Python 3 for testing, we have to be more explicit about converting between binary and string representations. I believe this should still work for Python 2, but I don't have a convenient way to try it out. Differential Revision: https://reviews.llvm.org/D26643 llvm-svn: 286909
* [Test-Suite] Fix all the sanitizer tests to be based on compiler capabilitiesChris Bieneman2016-11-108-8/+2
| | | | | | | | | | | | Summary: This patch reworks all the @skip... lines for sanitizer libraries to be based on whether or not the compiler actually works, rather than whether or not the compiler-rt sources are present in some magically derived directory. Reviewers: lldb-commits Subscribers: kubabrecka, tfiala Differential Revision: https://reviews.llvm.org/D26513 llvm-svn: 286490
OpenPOWER on IntegriCloud