summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* [lldb-mi] Move TestMIPrompt away from pexpect().Davide Italiano2019-02-202-58/+17
| | | | llvm-svn: 354506
* [lldb-mi] Remove a test that uses pexpect().Davide Italiano2019-02-201-82/+0
| | | | | | | | | | | | | | | | Summary: Its functionality is entirely covered by exec-run.test (which doesn't use pexpect) Reviewers: serge-sans-paille Subscribers: ki.stfu, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58459 llvm-svn: 354494
* [TestModuleCXX] Make this test Darwin-only.Jonas Devlieghere2019-02-201-1/+1
| | | | | | | Apparently this functionality is not expected to work on non-Darwin systems. I should've checked the decorator on the original test. llvm-svn: 354487
* [lldb] [test] Fix expected netbsd output for TestImageListMultiArchitectureMichal Gorny2019-02-201-1/+1
| | | | llvm-svn: 354483
* [lldb] [ObjectFile/ELF] Fix recognizing NetBSD imagesMichal Gorny2019-02-205-13/+64
| | | | | | | | | | | | | | | | | | | | | Split the recognition into NetBSD executables & shared libraries and core(5) files. Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged in the same way as regular NetBSD executables. Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG, IDENT_DECSZ, IDENT_NAMESZ and PROCINFO. The new values detect correctly the NetBSD images. The patch has been originally written by Kamil Rytarowski. I've added tests and applied minor code changes per review. The work has been sponsored by the NetBSD Foundation. Differential Revision: https://reviews.llvm.org/D42870 llvm-svn: 354466
* [TestModuleCXX] Use UNSUPPORTED instead of REQUIRESJonas Devlieghere2019-02-201-1/+1
| | | | | | | The requires value turns out to be bogus and the test gets skipped on macOS. llvm-svn: 354425
* [Instrumentation] Make API logging unconditionalJonas Devlieghere2019-02-201-4/+20
| | | | | | | | We should always log API calls in addition to logging whether the call was recorded as part of the reproducer. Since we already have the macro we might as well put that logic there. llvm-svn: 354424
* [lldb-instr] Group RECORD macrosJonas Devlieghere2019-02-202-4/+13
| | | | | | Group LLDB_RECORD macros per input file. llvm-svn: 354423
* Move -fcxx-modules to MANDATORY_MODULE_BUILD_CFLAGS (NFC)Adrian Prantl2019-02-201-3/+4
| | | | llvm-svn: 354418
* [lldbtest] Remove some accidentally commented out code.Davide Italiano2019-02-201-2/+0
| | | | llvm-svn: 354415
* [testsuite] Fix TestUnicodeString to work with Py2 and Py3.Davide Italiano2019-02-201-2/+2
| | | | llvm-svn: 354414
* [lldb-instr] Don't print REGISTER macro when RECORD is already presentJonas Devlieghere2019-02-192-8/+10
| | | | | | | | | | | Currently we'd always print the LLDB_REGISTER macro, even if the LLDB_RECORD macro was already present. This patches changes that to make it easier to incrementally update the macros. Note that it's still possible for the RECORD and REGISTER macros to get out of sync. llvm-svn: 354400
* Add Facebook Minidump directory streams and options to dump them.Greg Clayton2019-02-195-2/+267
| | | | | | | | Facebook creates minidump files that contain specific information about why things crash. Adding ways to dump these allows tools to be made that can auto download symbols based on the information that is contained in the minidump files. Differential Revision: https://reviews.llvm.org/D58398 llvm-svn: 354385
* Revert "minidump: Add ability to attach (breakpad) symbol files to ↵Pavel Labath2019-02-195-114/+52
| | | | | | | | | | | | | | | | | | placeholder modules" This reverts r354263, because it uncovered a problem in handling of the minidumps with conflicting UUIDs. If a minidump contains two files with the same UUID, we will not create to placeholder modules for them, but instead reuse the first one for the second instance. This creates a problem because these modules have their load address hardcoded in them (and I've added an assert to verify that). Technically this is not a problem with this patch, as the same issue existed in the previous implementation, but it did not have the assert which would diagnose that. Nonetheless, I am reverting this until I figure out what's the best course of action in this situation. llvm-svn: 354324
* Fix vscode tests for python3Pavel Labath2019-02-191-2/+2
| | | | | | | | encode/decode the data before sending it over the socket. Since (AFAICT) the vscode protocol (unlike the gdb-remote one) is fully textual, using the utf8 codec here is appropriate. llvm-svn: 354308
* [gui] Simplify SourceFileWindowDelegate::WindowDelegateDrawPavel Labath2019-02-191-5/+2
| | | | | | | | | instead of printf-ing into a buffer, and them using that buffer as a format string, simply use the appropriate indirect format string. This also fixes a -Wformat-truncation warning with gcc. llvm-svn: 354307
* [lldb-instr] Test that we ignore existing macros.Jonas Devlieghere2019-02-193-1/+13
| | | | | | Although the functionality was already present, it wasn't tested. llvm-svn: 354303
* [lldb-instr] Wrap returns of struct/classes in LLDB_RECORD_RESULTJonas Devlieghere2019-02-195-4/+50
| | | | | | | The instrumentation framework requires return values of custom classes and structs to be wrapped in the LLDB_RECORD_RESULT macro. llvm-svn: 354301
* Disable TestModuleCXX.test on WindowsJonas Devlieghere2019-02-191-0/+2
| | | | | | | | | | Importing cxx modules doesn't seem to work on Windows: error: a.out :: Class 'tagARRAYDESC' has a member 'tdescElem' of type 'tagTYPEDESC' which does not have a complete definition. error: a.out :: Class 'tagPARAMDESCEX' has a member 'varDefaultValue' of type 'tagVARIANT' which does not have a complete definition. llvm-svn: 354300
* [lldbtest] Fix some code to be compatible between py2 and py3.Davide Italiano2019-02-181-18/+4
| | | | llvm-svn: 354297
* [lldb-instr] Add constructor and move test into lit/toolsJonas Devlieghere2019-02-184-16/+26
| | | | | | | | The test had an implicit constructor for the Foo struct. Also, as the instrumentation doesn't have to be reproducer specific, I moved the tests into the lit/tools directory. llvm-svn: 354294
* One more fix while I'm looking at this - remove the Jason Molenda2019-02-181-7/+1
| | | | | | | | | unused IsSBProcess method, and have IsFBSProcess return false if we don't have API that we can use to make that determination, so we'll try other API if we can. llvm-svn: 354289
* Ah, misunderstood Jonas' feedback - fix this so we'llJason Molenda2019-02-181-1/+2
| | | | | | | do the right thing when both API are available. We want to try both of them if the first one fails. llvm-svn: 354288
* Clean up an unused variable warning when building this forJason Molenda2019-02-181-0/+4
| | | | | | mac native. llvm-svn: 354287
* [Python3] Fix TestObjCMethods.py to work with py2 and 3.Davide Italiano2019-02-181-1/+1
| | | | llvm-svn: 354286
* [Reproducers] Make clang use lldb's VFS.Jonas Devlieghere2019-02-1815-13/+82
| | | | | | | | | | In r353906 we hooked up clang and lldb's reproducer infrastructure to capture files used by clang. This patch adds the necessary logic to have clang reuse the files from lldb's reproducer during replay. Differential revision: https://reviews.llvm.org/D58309 llvm-svn: 354283
* Un-XFAIL TestLinuxCore for windowsPavel Labath2019-02-181-11/+0
| | | | | | | It turns out all that was needed to get this test passing was to fix the python3 incompatibility. llvm-svn: 354278
* Fix TestLinuxCore for python3Pavel Labath2019-02-181-4/+4
| | | | | | | - dictionaries don't have iteritems() - division returns floats llvm-svn: 354273
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-02-185-52/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r353677, which was reverted due to test failures on the windows bot. The issue there was that ObjectFilePECOFF vended its base address through the incorrect interface. SymbolFilePDB depended on that, which lead to assertion failures when SymbolFilePDB was attempting to use the placeholder object files as a base. This has been fixed in r354258 It also fixes one small problem in the original patch. The issue was that the Module class would attempt to overwrite the object file we created in CreateModuleFromObjectFile if the file corresponding to the placeholder object file happened to exist (but we have already disqualified it due to UUID mismatch. The fix is simple -- we set the m_did_load_objfile flag to properly record the fact that we have already created an object file for the module. The original commit message was: The reason this wasn't working was that ProcessMinidump was creating odd object-file-less modules, and SymbolFileBreakpad required the module to have an associated object file because it needed to get its base address. This fixes that by introducing a PlaceholderObjectFile to serve as a dummy object file. The general idea for this is taken from D55142, but I've reworked it a bit to avoid the need for the PlaceholderModule class. Now that we have an object file, our modules are sufficiently similar to regular modules that we can use the regular Module class almost out of the box -- the only thing I needed to tweak was the Module::CreateModuleFromObjectFile functon to set the module's FileSpec in addition to it's architecture. This wasn't needed for ObjectFileJIT (the other user of CreateModuleFromObjectFile), but it shouldn't hurt it either, and the change seems like a straightforward extension of this function. Reviewers: clayborg, lemo, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D57751 llvm-svn: 354263
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-185-3/+94
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Return better error message from GDBRemoteCommunication::ConnectLocallyPavel Labath2019-02-181-3/+4
| | | | llvm-svn: 354256
* Set cmake policy CMP0075 to NEWPavel Labath2019-02-181-0/+4
| | | | | | | | | | | | | | | | | | | Summary: The policy is about cmake_include_files ignoring CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this policy to NEW, but that is overridden by our cmake_minimum_required command. This makes our cmake policy setup consistent with the llvm build files and avoids a warning when using newer versions of cmake. Reviewers: sgraenitz, xiaobai Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58279 llvm-svn: 354251
* Remove unused extern declaration as removed by D32167Jan Kratochvil2019-02-171-2/+0
| | | | llvm-svn: 354225
* Add PythonBoolean type to the PythonDataObjectsTatyana Krasnukha2019-02-163-0/+103
| | | | | | Differential Revision: https://reviews.llvm.org/D57817 llvm-svn: 354206
* [testsuite] Skip this test correctly also on macOS.Davide Italiano2019-02-161-3/+2
| | | | llvm-svn: 354204
* Fix TestDataFormatterLibcxxListLoop.py testRaphael Isemann2019-02-161-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The compilation of the TestDataFormatterLibcxxListLoop.py currently fails with this error: ``` functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base<int, void *>' assert(third_elem->__value_ == 3); ~~~~~~~~~~ ^ ``` It seems the internal structure of list has changed with the 3.8 release. This patch makes the test compile with the current libc++ and with the previous libc++. Reviewers: shafik, zturner, labath Reviewed By: labath Subscribers: christof, jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D58273 llvm-svn: 354202
* Temporarily disable test:Richard Smith2019-02-161-1/+4
| | | | | | | | | test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly declared there, making the class template name C ambiguous. llvm-svn: 354185
* Add some unconditional logging on the failure points when attachingJason Molenda2019-02-153-42/+69
| | | | | | | | | | | | | | to a process so we'll always get messages in the console logs. Also make the "is frontboard process" / "is backboard process" determination lazy, specifically take it out of the MachProcess::AttachForDebug codepath when we are attaching to a process, to simplify attaching. <rdar://problem/47982516> <rdar://problem/48060134> llvm-svn: 354181
* Revert "Don't include UnixSignals.h from Host."Davide Italiano2019-02-1512-37/+22
| | | | | | It broke the modules green dragon buildbot. llvm-svn: 354177
* Fix AST generated for a class template to connect the class inside aRichard Smith2019-02-151-0/+1
| | | | | | | | | | | | | | | | class template back to the template. Previously, when the ASTImporter imported the class, it didn't know that it was the pattern of a class template, so made the class a name lookup result for the name of the template, resulting in ambiguity errors when naming the template. Due to a clang bug (fixed in r354091, reverted and soon to be re-committed), ambiguity errors between a template and a non-template were previously not diagnosed. Once r354091 is re-committed, this will be covered by existing lldb tests. llvm-svn: 354173
* [win] Resolve the module only if there isn't one alreadyStella Stamenova2019-02-153-14/+23
| | | | | | | | | | | | | | | | | | Summary: This commit modifies the OnLoadModule method to resolve the module unless we already have one Change by Hui Huang to fix the failing LLDB tests on Windows Reviewers: labath, asmith Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D58303 llvm-svn: 354172
* Don't include UnixSignals.h from Host.Zachary Turner2019-02-1512-22/+37
| | | | | | | | | | | | | | | | | Host had a function to get the UnixSignals instance corresponding to the current host architecture. This means that Host had to include a file from Target. To break this dependency, just make this a static function directly in UnixSignals. We already have the function UnixSignals::Create(ArchSpec) anyway, so we just need to have UnixSignals::CreateForHost() which determines which value to pass for the ArchSpec. The goal here is to eventually break the Host->Target->Host circular dependency. Differential Revision: https://reviews.llvm.org/D57780 llvm-svn: 354168
* Disable stop-hook-threads.test on LinuxJorge Gorbe Moya2019-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ExecControl/StopHook/stop-hook-threads.test is flaky on Linux (it's consistently failing on my machine, but doesn't fail on a co-worker's). I'm seeing the following assertion failure: ``` CommandObject.cpp:145: bool lldb_private::CommandObject::CheckRequirements(lldb_private::CommandReturnObject&): Assertion `m_exe_ctx.GetTargetPtr() == NULL' failed. ``` Interestingly, this doesn't happen when typing the same commands in interactive mode. The cause seems to be that, in synchronous execution mode continue waits until the process stops again, and that includes running any stop-hooks for that later stop, so we end with a stack trace like this (lots of frames omitted for clarity): ``` abort() CommandObject::CheckRequirements() <-- this is again the same instance of CommandObjectProcessContinue, fails assertion because the previous continue command hasn't finished. Target::RunStopHooks() CommandObjectProcessContinue::DoExecute() Target::RunStopHooks() ``` In general, it seems like using process control commands inside stop-hooks does not have very well defined semantics. You don't even need multiple threads to make that assertion fail, you can build ``` int main() { printf("1\n"); // break1 printf("2\n"); // break2 } ``` and then on lldb ``` target stop-hook add -o continue break set -f stop-hook-simple.cpp -p "break1" break set -f stop-hook-simple.cpp -p "break2" run ``` In this case it's even worse because the presence of multiple threads makes it prone to race conditions. In some tests I ran with a simpler version of this test case, I was hitting either the previous assertion failure or the following issue: 1. Two threads reach a breakpoint 2. First stop-hook does a process continue 3. Threads end 4. Second stop-hook runs, complains about process not existing. This change disables the test on Linux. It's already marked as XFAIL on Windows, so maybe we should just delete it until it's clear what should be the expected behavior in these cases. Or maybe try to come up with a way to write a similar multithreaded test without calling continue from a stop hook, I don't know. Differential Revision: https://reviews.llvm.org/D58257 llvm-svn: 354149
* Fix potential UB when target_file directory is nullStefan Granitz2019-02-151-0/+5
| | | | | | | | | | | | | | Summary: As seen in a crash report, the C-string returned for the directory component of `target_file` can null. It should not be assigned to `std::string` directly as this is undefined behavior. Reviewers: jingham Reviewed By: jingham Subscribers: jdoerfert, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D57964 llvm-svn: 354145
* Remove alignment from struct XSAVE altogetherPavel Labath2019-02-151-1/+1
| | | | | | | | | | | | | I reduced the alignment of this struct in r342029 to avoid compiler warnings about under-aligned allocations, but it turns out that this still causes problems with some compilers (see r353778). As I hinted in r342029, I don't believe any special aligment is necessary here (the only reason for that would be if we used some aligned SSE instructions to access this buffer, but I don't see any reason why we should do that), so here I go all the way, and remove the alignment requirements (except the ones naturally imposed by basic types) altogether. llvm-svn: 354125
* [lldb] [MainLoop] Add kevent() EINTR handlingMichal Gorny2019-02-152-2/+32
| | | | | | | | | | | | | Add missing EINTR handling for kevent() calls. If the call is interrupted, return from Poll() as if zero events were returned and let the polling resume on next iteration. This fixes test flakiness on NetBSD. Includes a test case suggested by Pavel Labath on D42206. Differential Revision: https://reviews.llvm.org/D58230 llvm-svn: 354122
* Fix the gdb-client test suite for python3Pavel Labath2019-02-151-12/+5
| | | | | | | | | | This applies the same fix that was done in r354106 to the lldb-server test: bitcasting the string to a bytes object before sending it over a socket. Since the gdb-remote protocol occasionally contains binary data, and it does not assign any particular encoding to them, this is the right thing to do here. llvm-svn: 354114
* Sort files in source/Host/CMakeLists.txtPavel Labath2019-02-151-4/+4
| | | | llvm-svn: 354112
* Fix lldb-server test suite for python3Pavel Labath2019-02-156-16/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch finishes the python3-ification of the lldb-server test suite. It reverts the partial attempt in r352709 to encode/decode the string via utf8 before writing to the socket. This wasn't enough because the gdb-remote protocol can sometimes (but not very often) carry binary data, and the utf8 codec chokes on that. Instead I add utility functions to the "seven" module for performing "identity" transformations on the byte data. This basically drills back the hole in the python type system that the string/bytes distinction was supposed to plug. That is not ideal, but was the best solution of the alternatives I could come up with. The options I considered were: - make use of the type system to add type safety to the test suite: This required making a lot of changes to the test suite, since most of the strings would now become byte objects instead, and it was not even fully clear to me where to draw the line. One extreme solution would be to just use byte objects everywhere, as the protocol doesn't support non-ascii characters anyway. However, this appeared to be: a) weird, because most of the protocol actually deals with strings, but we would have to prefix everything with 'b' b) clunky, because the handling of the bytes objects is sufficiently different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an int in PY3). - using the latin1 codec (which gives an identity transformation for the first 256 code points of unicode) instead of the custom bytes_to_string functions. This almost could work, but it was still slightly different between python 2 and 3, because in PY2 in would return a unicode object, which would then cause problems when combined with regular strings if it contained 8-bit chars. With this in mind, I think the best solution for the time being is to just coerce everything into the string type as early as possible, and have things proceed indentically on both python versions. Once we stop supporting python3, we can revisit the idea of using bytes objects more prevasively. Reviewers: davide, zturner, serge-sans-paille Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D58177 llvm-svn: 354106
* Use sys.executable in lldb-dotestPavel Labath2019-02-151-1/+1
| | | | | | | | | | | Without that, dotest.py would be executed with the default python interpreter, which may not be the same one that lldb is built with. This still requires the user do know which python interpreter to use when running lldb-dotest, but now he is at least able to choose it, if he knows which one to use. llvm-svn: 354105
OpenPOWER on IntegriCloud