summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities
Commit message (Collapse)AuthorAgeFilesLines
* [test-suite] Add a decorator for the lack of libstdcxx on the system.Davide Italiano2018-07-069-26/+9
| | | | | | | | | This generalizes a bunch of target-specific tests. MacOS has no libstdcxx anymore, and neither does FreeBSD (or Windows). <rdar://problem/41896105> llvm-svn: 336463
* Remove a bunch more references to _LIBCPP_INLINE_VISIBILITYJim Ingham2018-07-068-40/+18
| | | | | | | | and adjust the tests that needed it to set their breakpoints more robustly. <rdar://problem/41867390> llvm-svn: 336403
* Don't muck with _LIBCPP_INLINE_VISIBILITY just to get predictable line table ↵Jim Ingham2018-07-051-9/+8
| | | | | | | | | | | | | | | entries. This test was trying to stop at a variety of std::vector calls. It looks like the test was failing because various inlined std functions left no line table entries for the line that invoked the inlined function. The author worked around that by undefining _LIBCPP_INLINE_VISIBILITY. That's an internal libcxx macro, we really shouldn't be playing around with it. Better to just force ourselves to stop where we want using some other non-inlineable statement. printf seems a good candidate... <rdar://problem/41867390> llvm-svn: 336397
* Fix and simplify lldb.command decoratorDave Lee2018-07-043-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes one issue with `lldb.command`, and also reduces the implementation. The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`. Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously. Additionally, the implementation was updated to: * Remove inner class * Remove use of `inspect` module * Remove `*args` and `**kwargs` Reviewers: clayborg Reviewed By: clayborg Subscribers: keith, xiaobai, lldb-commits Differential Revision: https://reviews.llvm.org/D48658 llvm-svn: 336287
* [lldbsuite, windows] Don't crash LLDB when we try to retrieve a register on ↵Stella Stamenova2018-07-022-2/+3
| | | | | | | | | | | | | | | | Windows Summary: 1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case 2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues. Reviewers: asmith, labath, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48844 llvm-svn: 336147
* Fix TestLoadUsingPaths on linuxPavel Labath2018-06-291-0/+1
| | | | | | | we need to explicitly link the test program with -ldl for the dlopen function to be available. llvm-svn: 335956
* Add a way to load an image using a library name and list of paths.Jim Ingham2018-06-286-0/+184
| | | | | | | | | | This provides an efficient (at least on Posix platforms) way to offload to the target process the search & loading of a library when all we have are the library name and a set of potential candidate locations. <rdar://problem/40905971> llvm-svn: 335912
* [lldbsuite] Fix TestBreakpointHitCount on WindowsStella Stamenova2018-06-281-1/+1
| | | | | | | | | | | | Summary: On Windows, the newer DIA SDKs end up producing function names that contain the return type as well. This means that the function name returned in the test will contain the return type (int) in addition to the name of the function and the type of the input (a(int)). To account for the possibility of both, the test should pass if the function name matches either pattern. Reviewers: zturner, asmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48654 llvm-svn: 335906
* Skip core file tests on build configurations lacking necessary componentsPavel Labath2018-06-281-0/+10
| | | | | | | | | | | | | | | | | | | Summary: To successfully open a core file, we need to have LLVM built with support for the relevant target. Right now, if one does not have the appropriate targets configured, the tests will fail. This patch uses the GetBuildConfiguration SB API to inform the test (and anyone else who cares) about the list of supported LLVM targets. The test then uses this information to approriately skip the tests. Reviewers: clayborg, jingham Subscribers: martong, lldb-commits Differential Revision: https://reviews.llvm.org/D48641 llvm-svn: 335859
* This is not a debug info sensitive test.Jim Ingham2018-06-261-0/+2
| | | | llvm-svn: 335688
* Fix TestThreadExit for gcc&libc++ comboPavel Labath2018-06-251-1/+2
| | | | | | | | | | | | | | | | pseudo_barrier_wait() begins by decrementing an atomic variable. Since these are always_inline in libc++, there is no line table anchor to break on before we decrement it. This meant that on gcc we stopped after the variable has been decremented, which meant that thread2 could have exited, violating the test setup. On clang this wasn't a problem because it generated some line table entries for the do{}while(0) loop in the macro, so we still ended up stopping, before we touched the variable. I fix this by adding a dummy statement before the pseudo_barrier_wait() command and setting the breakpoint there. llvm-svn: 335476
* Make testcase classnames uniqueJan Kratochvil2018-06-243-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Filenames with test results contain only the class name which makes it more difficult to find it if the same class name is present in multiple *.py files. packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py -class ReturnValueTestCase(TestBase): +class StepAvoidsNoDebugTestCase(TestBase): as ReturnValueTestCase is already present in: packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py -class CreateDuringStepTestCase(TestBase): +class CrashDuringStepTestCase(TestBase): as CreateDuringStepTestCase is already present in: packages/Python/lldbsuite/test/functionalities/thread/create_during_step/TestCreateDuringStep.py packages/Python/lldbsuite/test/functionalities/thread/step_until/TestStepUntil.py -class TestCStepping(TestBase): +class StepUntilTestCase(TestBase): as TestCStepping is already present in: packages/Python/lldbsuite/test/lang/c/stepping/TestStepAndBreakpoints.py llvm-svn: 335431
* [DataFormatter] Add CFDictionary data formatterJonas Devlieghere2018-06-212-1/+10
| | | | | | | | Add data formatter for NSCFDictionary/CFDictionaryRef. Differential revision: https://reviews.llvm.org/D48450 llvm-svn: 335271
* Make test sources compatible with android+libcxx+modulesPavel Labath2018-06-201-45/+45
| | | | | | | | | | | | | | In a modules build, android is very picky about which symbols are visible after including libc++ headers (e.g. <cstdio> defines only std::printf and not ::printf). This consolidates the tests where this was an issue to always include the <c???> version of the headers and prefixes the symbols with std:: as necessary. Apart from that, there is no functional change in the tests. llvm-svn: 335149
* Make sure TestNumThreads works with libc++Pavel Labath2018-06-202-2/+6
| | | | | | | | | | | | | | | | The problem was that with libc++ the std::unique_lock declaration was completely inlined, so there was no line table entry in the main.cpp file to set a breakpoint on. Therefore, the breakpoint got moved to the next line, but that meant the test would deadlock as the thread would stop with the lock already held. I fix that issue by adding a dummy statement before the std::unique_lock line to anchor the breakpoint. I think this should fix the issue because of which this test was disabled on darwin, but someone should verify that before enabling it. llvm-svn: 335132
* Make TestCommandScript.py NO_DEBUG_INFO_TESTCASEPavel Labath2018-06-191-0/+1
| | | | llvm-svn: 335051
* Fix the 'tb' alias commandFrederic Riss2018-06-181-0/+25
| | | | | | | No idea when this broke or if it ever worked. Added a small test for one-shot breakpoints while I was there. llvm-svn: 334921
* Fix TestExec after r334783Frederic Riss2018-06-151-8/+1
| | | | | | | | | | | | The second makefile that was added has implicit rules which meant that secondprog.cpp would be built once into a secondprog binary, but it would also be compiled as a.out overwriting the main binary. This lead to spurious failures. This commit simplifies the Makefile to build only once with the correct executable name. llvm-svn: 334861
* Change TestExec.py from creating an i386+x86_64 fat binaryJason Molenda2018-06-155-90/+87
| | | | | | | | | | on darwin systems and re-execing itself, to creating two separate test programs; lldb runs the first program and it exec's the second. Support for compiling for i386 is going away. llvm-svn: 334783
* [lit] Split test_set_working_dir TestProcessLaunch into two tests and fix it ↵Stella Stamenova2018-06-131-11/+28
| | | | | | | | | | | | | | | | | | | | | | on Windows Summary: test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails. During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable). This change also fixes both the positive and negative cases on Windows. There were a few issues: 1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success. 2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF). 3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string. Reviewers: labath, zturner, asmith, jingham Reviewed By: labath Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48050 llvm-svn: 334642
* [ObjC] Add dataformatter for NSDecimalNumberJonas Devlieghere2018-06-132-1/+13
| | | | | | | | | | This patch adds a data formatter for NSDecimalNumber. The latter is a Foundation object used for representing and performing arithmetic on base-10 numbers that bridges to Decimal. Differential revision: https://reviews.llvm.org/D48114 llvm-svn: 334638
* Fix/unify the spelling of Objective-C.Adrian Prantl2018-06-131-1/+1
| | | | llvm-svn: 334614
* Add a new SBTarget::LoadCore() overload which surfaces errors if the load failsLeonard Mosescu2018-06-111-0/+18
| | | | | | | | | | | | | There was no way to find out what's wrong if SBProcess SBTarget::LoadCore(const char *core_file) failed. Additionally, the implementation was unconditionally setting sb_process, so it wasn't even possible to check if the return SBProcess is valid. This change adds a new overload which surfaces the errors and also returns a valid SBProcess only if the core load succeeds: SBProcess SBTarget::LoadCore(const char *core_file, SBError &error); Differential Revision: https://reviews.llvm.org/D48049 llvm-svn: 334439
* Fix tuple getter in std unique pointer pretty-printerPavel Labath2018-06-112-0/+16
| | | | | | | | | | | | | Summary: Check case when _M_t child member is not present. Reviewers: labath, tberghammer Reviewed By: labath, tberghammer Differential Revision: https://reviews.llvm.org/D47932 Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>. llvm-svn: 334411
* [lit, windows] Disable a number of tests that are failing on WindowsStella Stamenova2018-06-078-0/+21
| | | | | | | | | | | | | | Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests. Reviewers: asmith, zturner, labath Reviewed By: zturner Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D47892 llvm-svn: 334210
* XFAIL TestMachCore for windows hostsPavel Labath2018-05-291-0/+1
| | | | | | | | It's been failing since I enabled the test for non-darwin targets. I made it reference the same bug as the linux core, as it's likely that the root cause is the same. llvm-svn: 333401
* Typo fixes.Bruce Mitchener2018-05-295-7/+7
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* Enable ProcessMachCore plugin on non-apple platformsPavel Labath2018-05-222-2/+0
| | | | | | | | | | | | | | | | | | | Summary: The plugin already builds fine on other platforms (linux, at least). All that was necessary was to revitalize the hack in PlatformDarwinKernel (not a very pretty hack, but it gets us going at least). I haven't done a thorough investigation of the state of the plugin on other platforms, but at least the two core file tests we have seem to pass, so I enable them. Reviewers: JDevlieghere, jasonmolenda Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D47133 llvm-svn: 332997
* Fix _NSCFBoolean data formatter.Jonas Devlieghere2018-05-181-2/+4
| | | | | | | | | | | | | In r265181 the test for the NSCFBoolean data formatter was removed. Later, in r279353 and r279446 a new implementation was provided for the formatter, which I believe never worked (and this wasn't caught because the test was never re-enabled). This commit fixes the bug and re-enables the old test case. Differential revision: https://reviews.llvm.org/D47014 llvm-svn: 332700
* [lit, lldbsuite] Disable tests that are failing because of pr21765 and pr24489Stella Stamenova2018-05-171-0/+1
| | | | | | | | | | | | | | Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489 Reviewers: asmith, labath, zturner Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47018 llvm-svn: 332629
* [lit] Fix several tests that fail when using Python 3 or on WindowsStella Stamenova2018-05-142-6/+16
| | | | | | | | | | | | | | | | Summary: 1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately 2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead Reviewers: asmith, labath, zturner Reviewed By: labath Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46773 llvm-svn: 332293
* [lit, lldbsuite] Add a bug reference to the failing TestLinuxCore and fix an ↵Stella Stamenova2018-05-091-10/+10
| | | | | | | | | | | | | | | | | | undefined property in dotest.py Summary: 1) In TestLinuxCore rather than skipping the tests on Windows, mark them as expected failures and add a bug reference 2) In dotest.py replace the undefined property in the exceptions with the actual property causing the exception Reviewers: asmith, labath, zturner Reviewed By: labath, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46590 llvm-svn: 331886
* [lit, lldbsuite] Fixes for several tests LLDB tests for Python 3 or WindowsStella Stamenova2018-05-071-0/+3
| | | | | | | | | | | | | | | | | Summary: In decorators.py, when opening streams, open them in text mode. In Py3, if they are not opened in text mode, the data is also expected to be binary, but we always use text data. In TestLinuxCore, skip the tests that are not applicable on Windows In the python api main.c, update the code to be compilable on Windows Reviewers: asmith, zturner Reviewed By: zturner Subscribers: zturner Differential Revision: https://reviews.llvm.org/D46440 llvm-svn: 331686
* Use the UUID from the minidump's CodeView Record for placeholder modulesLeonard Mosescu2018-05-022-9/+68
| | | | | | | | | | | | | | | This change adds support for two types of Minidump CodeView records: PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html) This is by far the most common record type. ELF BuildID (found in Breakpad/Crashpad generated minidumps) This would set a proper UUID for placeholder modules, in turn enabling an accurate match with local module images. Differential Revision: https://reviews.llvm.org/D46292 llvm-svn: 331394
* Attempt to fix TestMiniDump on windowsPavel Labath2018-04-191-6/+6
| | | | | | | | | | | | | | | | | | | | | | | It was failing because the modules names were coming out as C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on windows. There are two issues at play here: - the first problem is that the paths in minidump were being parsed as a host path. This meant that on posix systems the whole path was interpreted as a file name. - on windows the path was split into a directory-filename pair correctly, but then when it was reconsituted, the last separator ended up being a forward slash because SBFileSpec.fullpath was joining them with '/' unconditionally. I fix the first issue by parsing the minidump paths according to the path syntax of the host which produced the dump, which should make the test behavior on posix&windows identical. The last path will still be a forward slash because of the second issue. We should probably fix the "fullpath" property to do something smarter in the future. llvm-svn: 330314
* Improve LLDB's handling of non-local minidumpsLeonard Mosescu2018-04-182-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, LLDB is creating a high-fidelity representation of a live process, including a list of modules and sections, with the associated memory address ranges. In order to build the module and section map LLDB tries to locate the local module image (object file) and will parse it. This does not work for postmortem debugging scenarios where the crash dump (minidump in this case) was captured on a different machine. Fortunately the minidump format encodes enough information about each module's memory range to allow us to create placeholder modules. This enables most LLDB functionality involving address-to-module translations. Also, we may want to completly disable the search for matching local object files if we load minidumps unless we can prove that the local image matches the one from the crash origin. (not part of this change, see: llvm.org/pr35193) Example: Identify the module from a stack frame PC: Before: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 frame #1: 0x00167c79 frame #2: 0x00167e6d frame #3: 0x7510336a frame #4: 0x77759882 frame #5: 0x77759855 After: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll Example: target modules list Before: error: the target has no associated executable images After: [ 0] C:\Windows\System32\MSVCP120D.dll [ 1] C:\Windows\SysWOW64\kernel32.dll [ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe [ 3] C:\Windows\System32\MSVCR120D.dll [ 4] C:\Windows\SysWOW64\KERNELBASE.dll [ 5] C:\Windows\SysWOW64\ntdll.dll NOTE: the minidump format also includes the debug info GUID, so we can fill-in the module UUID from it, but this part was excluded from this change to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or 20 bytes, while the CodeView GUIDs are normally 24 bytes) Differential Revision: https://reviews.llvm.org/D45700 llvm-svn: 330302
* Report more precise error message when attach failsPavel Labath2018-04-182-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the remote stub sends a specific error message instead of just a E?? code, we can use this to display a more informative error message instead of just the generic "unable to attach" message. I write a test for this using the SB API. On the console this will show up like: (lldb) process attach ... error: attach failed: <STUB-MESSAGE> if the stub supports error messages, or: error: attach failed: Error ?? if it doesn't. Reviewers: jingham, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45573 llvm-svn: 330247
* [Statistics] Relax the test output a little bit.Davide Italiano2018-04-161-4/+4
| | | | | | | | | | We don't really care about the order as this is a dictionary. It should be more resilient to changes (adding/shuffling stats around). Pointed out by Jason Molenda in a post-commit review (thanks Jason). llvm-svn: 330170
* [Commands] Expose statistics through the SBAPI.Davide Italiano2018-04-163-0/+34
| | | | | | | | | The API is `SBStructuredData GetStatistics()`. This allows the command to be used in scripts. <rdar://problem/36555975> llvm-svn: 330165
* Make sure deleting all breakpoints clears their sites firstEugene Zemtsov2018-04-162-0/+23
| | | | | | | | Bug: https://bugs.llvm.org/show_bug.cgi?id=36430 Differential Revision: https://reviews.llvm.org/D45554 llvm-svn: 330163
* [Command] Implement `statistics` command.Davide Italiano2018-04-133-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to collect useful metrics about lldb debugging sessions. I thought that an example would be better than a thousand words: Process 19705 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x0000000100000fb4 blah`main at blah.c:3 1 int main(void) { 2 int a = 6; -> 3 return 0; 4 } (lldb) statistics enable (lldb) frame var a (int) a = 6 (lldb) expr a (int) $1 = 6 (lldb) statistics disable (lldb) statistics dump Number of expr evaluation successes : 1 Number of expr evaluation failures : 0 Number of frame var successes : 1 Number of frame var failures : 0 Future improvements might include: 1. Passing a file, or implementing categories. The way this patch has been implemented is generic enough to allow this to be extended easily without breaking the grammar. 2. Adding an SBAPI and Python API for use in scripts. Thanks to Jim Ingham for discussing the design with me. <rdar://problem/36555975> Differential Revision: https://reviews.llvm.org/D45547 llvm-svn: 330043
* Allow relative file paths when settings source breakpointsGreg Clayton2018-04-131-1/+25
| | | | | | | | | | | | | | | | | Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like: ./main.c ./src/main.c src/main.c foo/bar/src/main.c I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project. Differential Revision: https://reviews.llvm.org/D45592 llvm-svn: 330028
* Re-land "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-132-0/+95
| | | | | | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 The original revision (r329891) was reverted because the associated tests ran into a deadlock on the Linux bots. That problem was resolved by r330002. llvm-svn: 330005
* Revert "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-122-95/+0
| | | | | | | This reverts r329891 because the test case is timing out on linux: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/21834 llvm-svn: 329897
* Don't assume backing thread shares protocol ID.Jonas Devlieghere2018-04-122-0/+95
| | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 llvm-svn: 329891
* Fix TestDisassembleBreakpoint broken by r328488Pavel Labath2018-03-262-33/+22
| | | | | | | | | | | | | | | | | The first issue was that the test was capturing the "before" disassembly before launching, and the "after" after. This is a problem because some of the disassembly will change after we know the load address (e.g. PCs in call instructions). I fix this by capturing both disassemblies with the process running. The second issue was that the refactor in r328488 accidentaly changed the meaning of the test, as it was no longer disassembling the function which contained the breakpoint. While inside, I also modernize the test to use lldbutil.run_to_source_breakpoint and prevent debug-info replication. llvm-svn: 328504
* Add and fix some tests for PPC64Pavel Labath2018-03-264-35/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: TestExprsChar.py Char is unsigned char by default in PowerPC. TestDisassembleBreakpoint.py Modify disassemble testcase to consider multiple architectures. TestThreadJump.py Jumping directly to the return line on PowerPC architecture dos not means returning the value that is seen on the code. The last test fails, because it needs the execution of some assembly in the beginning of the function. Avoiding this test for this architecture. TestEhFrameUnwind.py Implement func for ppc64le test case. TestWatchLocation.py TestStepOverWatchpoint.py PowerPC currently supports only one H/W watchpoint. TestDisassembleRawData.py Add PowerPC opcode and instruction for disassemble testcase. Reviewers: labath Reviewed By: labath Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc Differential Revision: https://reviews.llvm.org/D44472 Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>. llvm-svn: 328488
* Add a test for setting the load address of a module with differing ↵Pavel Labath2018-03-261-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | physical/virtual addresses Summary: First attempt at landing D42145 was reverted because it caused test failures on some android devices. It turned out this was because these devices had vdso modules with differing physical and virtual addresses. This was not caught earlier because all of the modules in our tests either lack physical addresses or have them identical to virtual ones. In the discussion on the patch, we came to the conclusion that in the scenario where we are merely setting a load address of a module (for example from a dynamic loader plugin), we should always use virtual addresses (i.e., preserve status quo). This patch adds a test to make sure we don't regress in that direction. Reviewers: owenpshaw Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44738 llvm-svn: 328485
* Last batch of test-tree cleaning changesPavel Labath2018-03-212-47/+38
| | | | | | | | | | | | | | | - postmortem tests: make sure the core files are created in the build folder - TestSourceManager: copy the .c file into the build dir before modifying it - TestLogging: create log files in the build folder After these changes I get a clean test run (on linux) even if I set the source tree to be read only. It's possible some of the skipped/xfailed tests are still creating files in the source tree, but at the moment, I don't have plans to go hunting for those. llvm-svn: 328106
* [LLDB] Fix TestTargetXMLArch's expected archPavel Labath2018-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When running on an architecture other than x86_64, the target.ConnectRemote() part of the test may add platform information to the target triple. It was observed that this happens at Process::CompleteAttach() method, after the platform_sp->IsCompatibleArchitecture() check fails. This method then calls platform_sp->GetPlatformForArchitecture(), that on a Linux machine ends up returning a generic Linux platform, that then ends up getting added to the original target architecture. Reviewers: clayborg, labath, jasonmolenda Reviewed By: labath Subscribers: alexandreyy, lbianc Differential Revision: https://reviews.llvm.org/D44022 Patch by Leandro Lupori <leandro.lupori@gmail.com>. llvm-svn: 327981
OpenPOWER on IntegriCloud