summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* Add llvm-dwarfdump to the list of test dependenciesPavel Labath2019-08-011-0/+1
| | | | | | It is used by SymbolFile/DWARF/debug-types-dwo-cross-reference.cpp llvm-svn: 367554
* [lit] Use ld.lld -z separate-code to work around a debug_line parsing bugFangrui Song2019-08-015-5/+5
| | | | | | | | | | | | | The issue was exposed by D64903/r367537. http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7321/ In these tests, .debug_str immediately follows .text. The last section of last RX PT_LOAD was originally padded with trap instructions and .debug_str started at a new page (actually common-page-size). Now, .debug_str immediately follows .test. Add -z separate-code to use the old layout. llvm-svn: 367549
* [lldb][NFC] Make ClangDiagnostic::m_fixit_vec privateRaphael Isemann2019-08-011-0/+1
| | | | llvm-svn: 367542
* [lldb][docs] Update landing page for monorepoStefan Granitz2019-08-012-11/+17
| | | | | | | | | | | | | | | | Summary: Following up from D65330, here's an update for the landing page. Reviewers: jryans, clayborg, amccarth, labath Reviewed By: jryans, amccarth, labath Subscribers: arphaman, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65437 llvm-svn: 367539
* [lldb][CMake] Avoid 'Autogenerate scheme' dialogs in Xcode projectsStefan Granitz2019-08-011-0/+1
| | | | | | | | | | | | | | | | | | Summary: Supported in CMake 3.9 and higher: https://cmake.org/cmake/help/v3.9/variable/CMAKE_XCODE_GENERATE_SCHEME.html Older versions will just report it as unused in the end of the configuration process. Reviewers: jingham, JDevlieghere Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65509 llvm-svn: 367538
* [Reproducers] Force replay in synchronous mode.Jonas Devlieghere2019-07-312-1/+18
| | | | | | | | | Replaying a reproducer in asynchronous mode never makes sense. This patch disables asynchronous mode during replay. Differential revision: https://reviews.llvm.org/D65547 llvm-svn: 367494
* [GDBRemote] Reflow comments and improve docs.Jonas Devlieghere2019-07-311-31/+35
| | | | | | | | Improved the GDB client base documentation while I was reading through it. Looks like it got messed up during the automatic comment reflow a while ago. llvm-svn: 367481
* [API] Remove use of ClangASTContext from SBTargetAlex Langford2019-07-313-13/+42
| | | | | | | | | | | | | Summary: The methods to find types in a Target aren't clang specific and are pretty generalizable to type systems. Additionally, to support some of the use cases in SBTarget, I've added a "GetScratchTypeSystems" method to Target to support getting all type systems for a target we are debugging. Differential Revision: https://reviews.llvm.org/D64964 llvm-svn: 367480
* [CommandCompletions] Remove commented out code.Jonas Devlieghere2019-07-311-8/+0
| | | | | | We use version control here. llvm-svn: 367459
* Fix completion for functions in anonymous namespacesJonas Devlieghere2019-07-313-1/+11
| | | | | | | | | | | | | | | | | I was going through some of the old bugs and came across PR21069 which I was able to reproduce. The issue is that we match the regex `^foo` against the `DW_AT_name` in the DWARF, which for our anonymous function is indeed `foo`. However, when we get the function name from the symbol context, the result is `(anonymous namespace)::foo()`. This throws off completions, which assumes that it's appending to whatever is already present on the input, resulting in a bogus `b fooonymous\ namespace)::foo()`. Bug report: https://llvm.org/PR21069 Differential revision: https://reviews.llvm.org/D65498 llvm-svn: 367455
* Don't crash when pass by value struct has no definition.Greg Clayton2019-07-311-1/+1
| | | | llvm-svn: 367441
* [lldb][NFC] Check in completion crash test caseRaphael Isemann2019-07-313-0/+18
| | | | llvm-svn: 367420
* Fix issues with inferior stdout coming out of orderPavel Labath2019-07-314-92/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had a bug where two pieces of code, executing on two threads were attempting to write inferior output simultaneously. The first one was in Debugger::HandleProcessEvent, which handled the cases where stdout was coming while the process was running. The second was in CommandInterpreter::IOHandlerInputComplete, which was ensuring that any output is printed before the command which caused process to run terminates. Both of these things make sense, but the fact they were implemented as two independent functions without any synchronization meant that race conditions could occur (e.g. both threads call process->GetSTDOUT, get two chunks of data, but then end up calling stream->Write in opposite order). This was most apparent in situations where a process quickly writes a bunch of output and then exits (as all our register tests do). This patch adds a mutex to ensure that stdout forwarding happens atomically. It also refactors a code somewhat in order to reduce code duplication. Reviewers: clayborg, jingham Subscribers: jfb, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65152 llvm-svn: 367418
* [lldb][NFC] Check in another crashing test caseRaphael Isemann2019-07-313-0/+18
| | | | llvm-svn: 367416
* [ProcessWindows] Choose a register context file by preprocessorTatyana Krasnukha2019-07-315-10/+19
| | | | | | | | | | Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows. Fixes llvm.org/pr42724 Differential Revision: https://reviews.llvm.org/D65409 llvm-svn: 367414
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-3120-35/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
* [lldb][NFC] Check in completion crash test in lambdaRaphael Isemann2019-07-313-0/+13
| | | | llvm-svn: 367411
* Add missing includes to SymbolFilePDBTestsPavel Labath2019-07-312-0/+2
| | | | | | These became needed after r367368. llvm-svn: 367410
* [lldb][docs] Add CMake version notes for -B flagStefan Granitz2019-07-312-4/+23
| | | | | | The original documentation update was reviewed with D65330 llvm-svn: 367407
* SymbolVendor: Remove the object file member variablePavel Labath2019-07-3119-141/+145
| | | | | | | | | | | | | | | | | | Summary: The last responsibility of the SymbolVendor was to hold an owning reference to the object file (in case symbols are being read from a different file than the main module). As SymbolFile classes already hold a non-owning reference to the object file, we can easily remove this responsibility of the SymbolVendor by making the SymbolFile reference owning. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65401 llvm-svn: 367392
* Change '|' to '&' in conditional.Richard Trieu2019-07-311-1/+1
| | | | | | | | Bitwise-or with a non-zero constant will always evaluate to true. Switch to bitwise-and which will only evalute to true if the specified bit is set in the other operand. llvm-svn: 367386
* [CompletionRequest] Remove unimplemented members.Jonas Devlieghere2019-07-3113-68/+21
| | | | | | | | | | Completion requests have two fields that are essentially unimplemented: `m_match_start_point` and `m_max_return_elements`. This would've been okay, if it wasn't for the fact that this caused a bunch of useless parameters to be passed around. Occasionally there would be a comment or assert saying that they are not supported. This patch removes them. llvm-svn: 367385
* [StringList] Change LongestCommonPrefix APIJonas Devlieghere2019-07-315-19/+11
| | | | | | | | | When investigating a completion bug I got confused by the API. LongestCommonPrefix finds the longest common prefix of the strings in the string list. Instead of returning that string through an output argument, just return it by value. llvm-svn: 367384
* [TableGen] Move helpers into LLDBTableGenUtils.Jonas Devlieghere2019-07-316-28/+62
| | | | | | | Instead of polluting the LLDBTableGenBackends header with helpers used by both emitters, move them into a separate files. llvm-svn: 367377
* [TableGen] Include vectorJonas Devlieghere2019-07-311-0/+1
| | | | | | Fixes "no member named 'vector' in namespace 'std'" compile error. llvm-svn: 367375
* [SymbolFilePDB] Fix windows bots after rL367360Alex Langford2019-07-301-4/+12
| | | | | | | | SymbolFilePDB tests were using GetTypeSystemForLanguage but weren't changed to accomodate the use of an llvm::Expected. I adjusted them accordingly. llvm-svn: 367368
* [TableGen] Reuse typedef across emitters (NFC)Jonas Devlieghere2019-07-303-18/+14
| | | | | | | This moves the std::map typedef into the header so it can be reused by all the emitter implementations. llvm-svn: 367363
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-3036-328/+596
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* [SymbolFile] SymbolFileDWARF::ParseLineTable should lock its moduleAlex Langford2019-07-301-1/+1
| | | | | | | | | As of svn rL367298, SymbolFileDWARF locks the module in many cases where it needs to parse some aspect of the DWARF symbol file. SymbolFileDWARF::ParseLineTable needs to lock the module because SymbolVendor::ParseLineTable no longer locks it. llvm-svn: 367358
* [Reproducers] Fix incorrect help messageJonas Devlieghere2019-07-301-2/+2
| | | | | | | The help message mentioned the `log` command (probably because I copied it from there originally). llvm-svn: 367338
* [dotest] Remove multiprocessingJonas Devlieghere2019-07-306-1913/+5
| | | | | | | | | | | Now that the Xcode project is removed, I want to focus on dotest as a test framework, and remove its driver capabilities for which we already rely on llvm's lit. Removing multiprocessing is the first step in that direction. Differential revision: https://reviews.llvm.org/D65311 llvm-svn: 367331
* [lldb][NFC] Fix import-std-module tests that relied on fix-its to passRaphael Isemann2019-07-302-5/+5
| | | | | | | These tests currently pass, but they rely on fix-its in our expression parser to pass because they have some typos. llvm-svn: 367309
* [lldb] Fix crash when tab-completing in multi-line exprRaphael Isemann2019-07-304-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way to do this is to go inside a frame with at least one local variable and then try to complete: (lldb) expr 1. a[tab] Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to become -1 which will lead to some out-of-bounds reading). Fixes rdar://51754005 I don't see any way to test this as the *multiline* expression completion is completely untested at the moment and I don't think we have any existing code for testing infrastructure for it. Reviewers: shafik, davide, labath Reviewed By: labath Subscribers: abidh, lldb-commits, davide, clayborg, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D64995 llvm-svn: 367308
* [lldb][NFC] Check in crashing test caseRaphael Isemann2019-07-303-0/+19
| | | | llvm-svn: 367307
* [lldb][docs] Update documentation for monorepo and CMake cachesStefan Granitz2019-07-301-36/+144
| | | | | | | | | | | | | | | | Summary: The lldb build system made good progress in the last months, but documentation was still lacking behind. Here's a patch to catch up. Reviewers: JDevlieghere, jingham, labath, stella.stamenova, teemperor, jryans, kastiglione, xiaobai, compnerd, zturner Reviewed By: labath, stella.stamenova, jryans Subscribers: clayborg, amccarth, friss, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65330 llvm-svn: 367302
* PECOFF: Fix a "memset clearing an object of non-trivial type" warningPavel Labath2019-07-302-34/+32
| | | | | | | | | | | | This time, the warning pointed to an actual problem, because the coff_opt_header structure contained a std::vector. I guess this happened to work because the all-zero state was a valid representation of an empty vector, but its not a good idea to rely on that. I remove the memset, and have the structure clear its members in the constructor instead. llvm-svn: 367299
* SymbolVendor: Move locking into the Symbol FilesPavel Labath2019-07-308-160/+126
| | | | | | | | | | | | | | | | | | | | | | Summary: The last bit of functionality in SymbolVendor passthrough functions is the locking the module mutex. While it may be nice doing the locking in a central place, we weren't really succesful in doing that right now, because some SymbolFile function could still be called without going through the SymbolVendor. This meant in SymbolFileDWARF (the only battle-tested symbol file implementation) roughly a half of the functions was taking additional locks and another half was asserting that the lock is already held. By making the SymbolFile responsible for locking, we can at least make the situation in SymbolFileDWARF more consistent. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D65329 llvm-svn: 367298
* [lldb] [test/lldb-vscode] Use realpath to match vscode behaviorMichal Gorny2019-07-301-2/+4
| | | | | | | | | | | Compare the directory paths returned by lldb-vscode against realpaths rather than apparent paths. This matches lldb-vscode behavior and therefore fixes test failures when one of the parent directories of the source tree is a symlink. Differential Revision: https://reviews.llvm.org/D65432 llvm-svn: 367291
* [lldb] [test/lldb-vscode] Use os.path.dirname() [NFC]Michal Gorny2019-07-301-5/+5
| | | | | | | Replace os.path.split()[0] with os.path.dirname(). Suggested by Pavel Labath in D65432. llvm-svn: 367290
* [lldb] [test] Mark newly running test XFAIL on NetBSDMichal Gorny2019-07-301-0/+1
| | | | | | | | The test was not previously run due to decorator bug (fixed in r366903). It is not a regression and is probably related to the other failing test, so just disable it. llvm-svn: 367285
* [NFC] avoid AlignedCharArray in lldbJF Bastien2019-07-292-3/+3
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. llvm-svn: 367275
* [CMake] Move project() call to main CMake fileHaibo Huang2019-07-292-2/+1
| | | | | | | | | | | | | | | Summary: The main CMake file don't have a project() call. In this case, cmake will run a dummy project(Project ) at the very beginning. Even before cmake_minimum_required. And a series of compiler detections will be triggered. This is problematic if we depends on some policy to be set. E.g. CMP0056. try_compile will fail before we have a chance to do anything. Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65362 llvm-svn: 367273
* [Symbolication] Remove some dead code. Nothing exciting.Davide Italiano2019-07-291-2/+0
| | | | llvm-svn: 367262
* [Symbolication] Remove a duplicate assignment.Davide Italiano2019-07-291-1/+0
| | | | llvm-svn: 367261
* [Symbolication] Fix unicode compatibility between 2 and 3.Davide Italiano2019-07-291-1/+1
| | | | | | | | | Triples are always ASCII for now, but we were handed out a unicode object. <rdar://problem/53592772> llvm-svn: 367260
* [Reproducers] Pass FileCollector around as a shared_ptr (NFC)Jonas Devlieghere2019-07-294-14/+19
| | | | | | | | | | | Instead of passing the FileCollector around as a reference or raw pointer, use a shared_ptr. This change's motivation is twofold. First it adds compatibility for the newly added `FileCollectorFileSystem`. Secondly, it addresses a lifetime issue we only see when LLDB is used from Xcode, where a reference to the FileCollector outlives the reproducer instance. llvm-svn: 367258
* Test load unloading of modules with libraries-svr4Antonio Afonso2019-07-291-0/+40
| | | | | | | | | | | | | | | | | | Summary: This doubles the 3 tests running right now on linux by also executing each test with libraries-svr4 enabled. Not sure if there's a better way to do this as I had to copy/paste all the decorators as well... Reviewers: labath, clayborg, xiaobai Reviewed By: labath Subscribers: srhines, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65129 llvm-svn: 367247
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-2934-71/+71
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-2916-129/+105
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* [lldb] Increase testsuite packet-timeout 5secs -> 1minJan Kratochvil2019-07-297-14/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | rL357954 did increase `packet-timeout` 1sec -> 5secs. Which is IMO about the maximum timeout reasonable for regular use. But for testsuite I think the timeout should be higher as the testsuite runs in parallel and it can be run even on slow hosts and with other load (moreover if it runs on some slow arch). I have chosen 60 secs, that should be enough hopefully. Larger value could make debugging with hanging `lldb-server` annoying. This patch was based on this testsuite timeout: http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/546/steps/test/logs/stdio FAIL: test_connect (TestGDBRemoteClient.TestGDBRemoteClient) Test connecting to a remote gdb server ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py", line 13, in test_connect process = self.connect(target) File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py", line 480, in connect self.assertTrue(error.Success(), error.description) AssertionError: False is not True : failed to get reply to handshake packet Differential Revision: https://reviews.llvm.org/D65271 llvm-svn: 367234
OpenPOWER on IntegriCloud