summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities
Commit message (Collapse)AuthorAgeFilesLines
* Fix test when using remote debugging.Pavel Labath2016-10-041-1/+1
| | | | | | | | | | | | | | Summary: Use os.getcwd() instead of get_process_working_directory() as prefix for souce file. Reviewers: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D25217 llvm-svn: 283171
* add a simple test case to validate test id()Todd Fiala2016-10-031-0/+17
| | | | | | | Since we count on it in a few places, the test verifies that the test instance has an id() method that returns something non-None. llvm-svn: 283156
* Fix up this test case.Jim Ingham2016-10-011-35/+0
| | | | | | | | | | | | | | The lldbutil.run_break_set_by_file_and_line has already checked that the number of locations was 1, so don't check it again. And certainly don't check it again by grubbing in break list output. Also, we know the Thread's IsStopped state is wrong, and have a test for that, so don't keep testing it in other files where that isn't the primary thing we're testing. I removed the xfail for Darwin. If this also passes on other systems, we can remove the xfails from them as we find that out. llvm-svn: 282993
* Fix up the test so it gets closer to passing.Jim Ingham2016-09-301-40/+11
| | | | | | | | | | | Remove the test for thread stopped states from this test. That isn't set properly now, and its setting doesn't matter till we actually support non-stop debugging, so we shouldn't have unrelated tests failing from it. Also changed some code that was trying and failing to grub command line output, and replaced it by SB API calls. llvm-svn: 282976
* Add the radar on our end to the bugreport string.Jim Ingham2016-09-301-3/+3
| | | | llvm-svn: 282970
* Add the radar from our end to the bugreport string.Jim Ingham2016-09-301-1/+1
| | | | llvm-svn: 282969
* IsValid is the way to ask a breakpoint location whether it is valid.Jim Ingham2016-09-301-2/+3
| | | | llvm-svn: 282966
* Add the tracking radar on our end.Jim Ingham2016-09-301-1/+1
| | | | llvm-svn: 282830
* Prefer skipping over x-failingEnrico Granata2016-09-301-1/+1
| | | | llvm-svn: 282824
* Do not assume we will be able to discover the return type of this selector ↵Enrico Granata2016-09-301-1/+1
| | | | | | call, for that is not true in i386 mode llvm-svn: 282823
* This test will not work in i386 mode because we don't create interesting ↵Enrico Granata2016-09-291-0/+1
| | | | | | | | types from the ObjC runtime "Fixes" rdar://28501616 llvm-svn: 282774
* Fix an issue where libc++ changed the type information we get for ↵Enrico Granata2016-09-282-10/+10
| | | | | | | | std::map::iterator, rendering LLDB unable to display elements vended by an iterator Fixes <rdar://problem/28237521> llvm-svn: 282648
* Add the ability for the task port to change when a process execs.Greg Clayton2016-09-281-1/+0
| | | | | | <rdar://problem/28476369> llvm-svn: 282632
* convert TestFatArchives.py over to no-debug-info testTodd Fiala2016-09-271-11/+4
| | | | | | | | | | We only use the .o-style debug info here regardless, so having it run all three debuginfo styles was a waste. This also strips out the custom build function and uses the TestBase.build() method. llvm-svn: 282508
* xfail TestExec.py on macOSTodd Fiala2016-09-271-0/+1
| | | | | | | Tracked by: rdar://28476369 llvm-svn: 282496
* Fix serialization of Python breakpoint commands.Jim Ingham2016-09-262-3/+3
| | | | | | | | | | | CommandData breakpoint commands didn't know whether they were Python or Command line commands, so they couldn't serialize & deserialize themselves properly. Fix that. I also changed the "breakpoint list" command to note in the output when the commands are Python commands. Fortunately only one test was relying on this explicit bit of text output. llvm-svn: 282432
* Remove ancient icc decoratorsPavel Labath2016-09-264-12/+0
| | | | | | | Nobody is running the test suite with icc, so we have no idea if they pass. But the bug they link to has definitely been fixed. llvm-svn: 282408
* Add the ability to append breakpoints to the save file.Jim Ingham2016-09-221-3/+57
| | | | llvm-svn: 282212
* Add the ability to deserialize only breakpoints matching a given name.Jim Ingham2016-09-221-1/+34
| | | | | | Also tests for this and the ThreadSpec serialization. llvm-svn: 282207
* add stop column highlighting supportTodd Fiala2016-09-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
* Probably should add the breakpoint names test directory as well...Jim Ingham2016-09-213-0/+200
| | | | llvm-svn: 282103
* Add some more tests for breakpoint serialization.Jim Ingham2016-09-201-45/+99
| | | | | | | | | | Serialize breakpoint names & the hardware_requested attributes. Also added a few missing affordances to SBBreakpoint whose absence writing the tests pointed out. <rdar://problem/12611863> llvm-svn: 282036
* First tests for serializing breakpoints.Jim Ingham2016-09-163-0/+206
| | | | | | Plus a few bug fixes I found along the way. llvm-svn: 281690
* xfail TestQueues.py and TestDarwinLogFilterMatchMessage.pyTodd Fiala2016-09-121-0/+8
| | | | | | | | | | | | | | It looks like the message-content-retrieval aspect of DarwinLog support is flaky, not just the regex match against it. Slightly less frequently than the regex matching, I am seeing the direct string-match variant of log-message-content matching also fail. Tracked by: llvm.org/pr30299 rdar://28237450 llvm-svn: 281251
* xfail DarwinLog "filter message by regex" testsTodd Fiala2016-09-091-0/+10
| | | | | | | | | | These tests are not working reliably. I'm marking them xfail until I resolve the issue. Tracked by: llvm.org/pr30299 llvm-svn: 281058
* [LLDB][MIPS] Fix TestEhFrameUnwind.py for MIPSNitesh Jain2016-09-091-3/+29
| | | | | | | | | | Reviewers: clayborg, labath Subscribers: jaydeep, bhushan, slthakur, lldb-commits Differential Revision: https://reviews.llvm.org/D24122 llvm-svn: 281031
* Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.Valentina Giusti2016-09-087-4/+172
| | | | | | | | | | | | Summary: Signed-off-by: Valentina Giusti <valentina.giusti@intel.com> Reviewers: dvlahovski, granata.enrico, clayborg, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24255 llvm-svn: 280942
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-06292-6323/+10201
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Revert "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."Dimitar Vlahovski2016-09-067-156/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rL280668 because the register tests fail on i386 Linux. I investigated a little bit what causes the failure - there are missing registers when running 'register read -a'. This is the output I got at the bottom: """ ... Memory Protection Extensions: bnd0 = {0x0000000000000000 0x0000000000000000} bnd1 = {0x0000000000000000 0x0000000000000000} bnd2 = {0x0000000000000000 0x0000000000000000} bnd3 = {0x0000000000000000 0x0000000000000000} unknown: 2 registers were unavailable. """ Also looking at the packets exchanged between the client and server: """ ... history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7 history[309] tid=0x7338 < 130> read packet: $name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:101;dwarf:101;#48 history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8 history[311] tid=0x7338 < 130> read packet: $name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:102;dwarf:102;#52 history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9 history[313] tid=0x7338 < 130> read packet: $name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:103;dwarf:103;#53 history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da history[315] tid=0x7338 < 130> read packet: $name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:104;dwarf:104;#54 history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db history[317] tid=0x7338 < 76> read packet: $name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99 history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc history[319] tid=0x7338 < 78> read packet: $name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e ... """ The bndcfgu and bndstatus registers don't have the 'Memory Protections Extension' set. I looked at the code and it seems that that is set correctly. So I'm not sure what's the problem or where does it come from. Also there is a second failure related to something like this in the tests: """ registerSet.GetName().lower() """ For some reason the registerSet.GetName() returns None. llvm-svn: 280703
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-0627-0/+466
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* Intel(R) Memory Protection Extensions (Intel(R) MPX) support.Valentina Giusti2016-09-057-4/+156
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The Intel(R) Memory Protection Extensions (Intel(R) MPX) associates pointers to bounds, against which the software can check memory references to prevent out of bound memory access. This patch allows accessing the MPX registers: * bnd0-3: 128-bit registers to hold the bound values, * bndcfgu, bndstatus: 64-bit configuration registers, This patch also adds read/write tests for the MPX registers in the register command tests and adds a new subdirectory for MPX specific tests. Signed-off-by: Valentina Giusti <valentina.giusti@intel.com> Reviewers: labath, granata.enrico, lldb-commits, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24187 llvm-svn: 280668
* Reapply "Make Scalar::GetValue more consistent"Pavel Labath2016-09-021-1/+0
| | | | | | | | this is a resubmission of r280476. The problem with the original commit was that it was printing out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and add a unit test covering that case. llvm-svn: 280480
* Revert "Make Scalar::GetValue more consistent"Pavel Labath2016-09-021-0/+1
| | | | | | | This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit breakage, and I did not run the 32-bit test suite before submitting, oops. llvm-svn: 280478
* Make Scalar::GetValue more consistentPavel Labath2016-09-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: It seems the original intention of the function was printing signed values in decimal format, and unsigned values in hex (without the leading "0x"). However, signed and unsigned long were exchanged, which lead to amusing test failures in TestMemoryFind.py. Instead of just switching the two, I think we should just print everything in decimal here, as the current behaviour is very confusing (especially when one does not request printing of types). Nothing seems to depend on this behaviour except and we already have a way for the user to request the format he wants when printing values for most commands (which presumably does not go through this function). I also add a unit tests for the function in question. Reviewers: clayborg, granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24126 llvm-svn: 280476
* Change the formula for tagged NSIndexPath data formattingEnrico Granata2016-09-013-0/+110
| | | | | | Fixes rdar://25192935 llvm-svn: 280389
* XFail TestMemoryFind on 32-bit architecturesPavel Labath2016-09-011-0/+2
| | | | | | | | the test fails for a very prosaic reason: `(const char *)0x1000` returns "4096" on x86_64 and "1000" (without the "0x") on i386. I haven't tried other 32-bit arches, but I am guessing the behaviour is the same. XFAIL until someone can get a chance to look at this. llvm-svn: 280344
* Change "memory find" over to using a variation of the Boyer–Moore search ↵Enrico Granata2016-09-013-0/+81
| | | | | | | | algorithm Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally) llvm-svn: 280327
* Add a data formatter for std::function in libcxxEnrico Granata2016-08-313-0/+80
| | | | llvm-svn: 280295
* Fix an issue where a synthetic child provider could only provide a value of ↵Enrico Granata2016-08-312-2/+22
| | | | | | the same size as the containing type llvm-svn: 280294
* Fixup TestPyObjSynthProvider.py and enable it againPavel Labath2016-08-312-1/+2
| | | | | | | | | | | | | | | Summary: - copies the new file in the cmake build - adds an additional import statement - marks the test as no-debug-info specific, as it seems to be testing a python feature Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24074 llvm-svn: 280261
* XFail new TestPyObjSynthProvider.py on linux until I can investigate the ↵Pavel Labath2016-08-311-0/+1
| | | | | | cause of the problem llvm-svn: 280208
* Rename the test classEnrico Granata2016-08-301-1/+1
| | | | llvm-svn: 280173
* Add an helper class lldb.formatters.synth.PythonObjectSyntheticChildProviderEnrico Granata2016-08-304-0/+95
| | | | | | | | This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues Comes with a test case llvm-svn: 280172
* Remove a test that depends on knowing all compiler's register allocation ↵Jim Ingham2016-08-191-23/+0
| | | | | | | | | | | schemes. This test was using a condition that would compare a variable against the register that would hold it. It was failing with clang on arm64 because clang put the variable on the stack. This is not a supportable way to write tests. llvm-svn: 279345
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-1943-0/+2291
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-1943-2291/+0
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-1943-0/+2291
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* Disable TestThreadSpecificBpPlusCondition on Windows.Zachary Turner2016-08-121-1/+1
| | | | | | Test frequently times out stalling the test runner. llvm-svn: 278529
* Skip 2 android test what is broken because of debuggerdTamas Berghammer2016-08-122-7/+2
| | | | | | | | | debuggerd is a crash reporting system on android what installs some signal handler for SEGV to print a backtrace in the log. Its behavior breaks tests where the test tries to continue after a SEGV so we skip them as this behavior isn't required on android anyway. llvm-svn: 278510
* Undid LLVM macro usage in test suite test subject files.Todd Fiala2016-08-101-7/+7
| | | | llvm-svn: 278197
OpenPOWER on IntegriCloud