summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* Return llvm::Error and llvm::Expected from DWARF parsing code.Zachary Turner2019-03-146-54/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal here is to improve our error handling and error recovery while parsing DWARF, while at the same time getting us closer to being able to merge LLDB's DWARF parser with LLVM's. To this end, I've udpated several of the low-level parsing functions in LLDB to return llvm::Error and llvm::Expected. For now, this only updates LLDB parsing functions and not LLVM. In some ways, this actually gets us *farther* from parity with the two interfaces, because prior to this patch, at least the parsing interfaces were the same (i.e. they all just returned bools, and now with this patch they're diverging). But, I chose to do this for two primary reasons. LLDB has error logging code engrained deep within some of its parsing functions. We don't want to lose this logging information, but obviously LLVM has no logging mechanism at all. So if we're to merge the interfaces, we have to find a way to still allow LLDB to properly report parsing errors while not having the reporting code be inside of LLVM. LLDB (and indeed, LLVM) overload the meaning of the false return value from all of these extraction functions to mean both "We reached the null entry at the end of a list of items, therefore everything was successful" as well as "something bad and unrecoverable happened during parsing". So you would have a lot code that would do something like: while (foo.extract(...)) { ... } But when the loop stops, why did it stop? Did it stop because it finished parsing, or because there was an error? Because of this, in some cases we don't always know whether it is ok to proceed, or how to proceed, but we were doing it anyway. In this patch, I solve the second problem by introducing an enumeration called DWARFEnumState which has two values MoreItems and Complete. Both of these indicate success, but the latter indicates that we reached the null entry. Then, I return this value instead of bool, and convey parsing failure separately. To solve the first problem (and convey parsing failure) these functions now return either llvm::Error or llvm::Expected<DWARFEnumState>. Having this extra bit of information allows us to properly convey all 3 of "error, bail out", "success, call this function again", and "success, don't call this function again". In subsequent patches I plan to extend this pattern to the rest of the parsing interfaces, which will ultimately get all of the log statements and error reporting out of the low level parsing code and into the high level parsing code (e.g. SymbolFileDWARF, DWARFASTParserClang, etc). Eventually, these same changes will have to be backported to LLVM's DWARF parser, but diverging in the short term is the easiest way to converge in the long term. Differential Revision: https://reviews.llvm.org/D59370 llvm-svn: 356190
* [DataFormatters] Delete unused code. Not even exposed in the API.Davide Italiano2019-03-144-31/+0
| | | | | | | I stumbled upon this while removing LLDB_DISABLE_PYTHON when not needed. llvm-svn: 356176
* Safer casting in ClangExpressionParser code completionRaphael Isemann2019-03-141-2/+2
| | | | | | | | | | | | | | | | | | Summary: Makes the code a bit safer in the unlikely situation that we don't get a ClangUserExpression when doing code completion. Reviewers: aprantl, jingham Reviewed By: aprantl Subscribers: labath, jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59359 llvm-svn: 356174
* [Python] Start eradicating unneeded LLDB_DISABLE_PYTHON guards.Davide Italiano2019-03-147-41/+1
| | | | | | | While we don't have a bot, I'm testing by hand that this configuration compiles. We'll probably set up one once I'm done flensing. llvm-svn: 356171
* [Reproducers] Fix data race found by tsanJonas Devlieghere2019-03-141-0/+2
| | | | | | | | This fixes a data race uncovered by tsan during destruction of the GDBRemoteReplay server. The solution is to lock the thread state mutex when receiving packets. llvm-svn: 356168
* Fix a double-overrelease in the TestDataFormatterObjC test program.Adrian Prantl2019-03-141-4/+5
| | | | llvm-svn: 356160
* Make sure that a sanitizer LLDB's environment doesn't get passed onAdrian Prantl2019-03-141-0/+5
| | | | | | to test binaries. llvm-svn: 356113
* [lldb-vscode] Don't try to launch an invalid program.Jorge Gorbe Moya2019-03-131-0/+1
| | | | | | | | | | | | | | | If an invalid program is specified, lldb-vscode will send back a response with "success" = false, but then will continue executing the rest of request_launch(), try to launch the program anyway and try to send another response (possibly using the `response` object after it was moved). This change adds a return statement so we stop executing the handler after producing the first failing response. Differential Revision: https://reviews.llvm.org/D59340 llvm-svn: 356110
* Reorder the operations inJason Molenda2019-03-131-21/+20
| | | | | | | | | | | | | | | | | | | | DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule a bit so that we only read the binaries out of memory once we've determined that we can find a real binary on the local system. Previously, lldb would read all of the kext binaries out of memory and then determine if it had the local copy. The kext table gives us most the information we need (address, name, uuid) so lldb only needs the actual in-memory load commands when it comes time to set the section load addresses. Delay reading until that point for all the kexts. NFC; doing the operations in a different order. <rdar://problem/41181173> llvm-svn: 356108
* [Python] Fix TestDataFormatterSmartArray to work across python versions.Davide Italiano2019-03-131-4/+4
| | | | | | | | | | | Python 3 default encoding is utf-8, so taking random bytes and interpreting them as a string might result in invalid unicode sequences. As the only thing we care about here is that the formatter shows the elements of the underyling array, relax the string matching (this is good enough as all the elements are distinct so they resolve to different strings). llvm-svn: 356096
* Fix an invalid static cast in ClangExpressionParser.cppAdrian Prantl2019-03-1316-20/+82
| | | | | | | | | | This was found by the green dragon sanitizer bot. rdar://problem/48536644 Differential Revision: https://reviews.llvm.org/D59314 llvm-svn: 356090
* [ExpressionParser] Restore removed intance of FileSystem::Resolve while ↵Alex Langford2019-03-131-0/+1
| | | | | | | | | resolving clang resource dir I committed a change that removed this line, but I meant to restore it befor committing. llvm-svn: 356079
* Update.Jason Molenda2019-03-131-6/+0
| | | | llvm-svn: 356073
* [lldbsuite] Un-xfail TestPyObjSynthProvider on WindowsStella Stamenova2019-03-131-1/+0
| | | | | | One of Davide's changes yesterday fixed the behavior on Windows, so the test is now passing. llvm-svn: 356065
* Make sure FileSystem::Resolve preserves the path/file distinction.Adrian Prantl2019-03-131-1/+4
| | | | | | This should finally fix TestPaths.py. llvm-svn: 356057
* Fix/unify SBType comparisonPavel Labath2019-03-133-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In my next step at cleaning up modify-python-lldb.py, I started focusing on equality comparison. To my surprise, I found out that both python and c++ versions of the SBType class implement equality comparison, but each one does it differently. While the python version was implemented in terms of type name equality, the C++ one used a deep comparison on the underlying objects. Removing the python version caused one test to fail (TestTypeList). This happened because the c++ version of operator== boiled down to TypePair::operator==, which contains two items: the compiler_type and type_sp. In this case, the compiler_type was identical, but one of the objects had the type_sp field unset. I tried fixing the code so that both objects keep their type_sp member, but it wasn't easy, because there are so many operations which just work with the CompilerType types, and so any operation on the SBType (the test in question was doing GetPointeeType on the type of one variable and expecting it to match the type of another variable), cause that second member to be lost. So instead, here I relax the equality comparison on the TypePair class. Now, this class ignores the type_sp for the purposes of comparison, and uses the CompilerType only. This seems reasonable, as each TypeSP is able to convert itself to a CompilerType. Reviewers: clayborg, aprantl, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D59217 llvm-svn: 356048
* [TestBatchMode] We already log this output to a file.Davide Italiano2019-03-131-12/+0
| | | | llvm-svn: 356003
* [testsuite] Remove other traces broken in python 3.Davide Italiano2019-03-131-31/+0
| | | | | | | They can be reinstated in case somebody needs to debug this test in the future. llvm-svn: 356002
* [testsuite] Remove dead code in TestFormats.Davide Italiano2019-03-131-27/+0
| | | | llvm-svn: 356000
* [test] Some unicode sequences can't be printed, and Py 3 is more picky.Davide Italiano2019-03-131-4/+0
| | | | | | | | Given this was under trace, it can just be removed. If somebody ever needs to debug this testcase again and print the data, they can add a new statement. llvm-svn: 355999
* [Python] Fix another batch of python 2/python 3 portability issues.Davide Italiano2019-03-134-10/+21
| | | | llvm-svn: 355998
* Update the macOS implementation of ComputeClangResourceDirectory toAdrian Prantl2019-03-121-3/+3
| | | | | | comply with the more pedantic TestPaths.py llvm-svn: 355994
* This test is failing on and off on the bots. Jim Ingham2019-03-121-1/+1
| | | | | | Disable it for now till I can figure out what's going wrong. llvm-svn: 355992
* Fix the broken Batch test by passing a custom module cache to the inferior lldb.Adrian Prantl2019-03-121-4/+7
| | | | llvm-svn: 355991
* Revert "Temporarily add more logging to TestBatchMode"Adrian Prantl2019-03-121-6/+0
| | | | llvm-svn: 355990
* Add XCOFF triple object format type for AIXJason Liu2019-03-121-0/+2
| | | | | | | | | This patch adds an XCOFF triple object format type into LLVM. This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform. Differential Revision: https://reviews.llvm.org/D58930 llvm-svn: 355989
* Temporarily add more logging to TestBatchModeAdrian Prantl2019-03-121-0/+6
| | | | llvm-svn: 355986
* Add more logging to ClangModulesDeclVendor.cppAdrian Prantl2019-03-121-0/+9
| | | | llvm-svn: 355985
* Remove support for DWARF64.Zachary Turner2019-03-1211-126/+34
| | | | | | | | | | | LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support for DWARF64 is only partial, and if enabled appears to also not work. Finally, it's untested. Removing this makes merging LLVM and LLDB's DWARF parsing implementations simpler. Differential Revision: https://reviews.llvm.org/D59235 llvm-svn: 355975
* Remove DWARFDIECollection.Zachary Turner2019-03-1214-143/+59
| | | | | | | | | | This is a very thin wrapper over a std::vector<DWARFDIE> and does not seem to provide any real value over just using a container directly. Differential Revision: https://reviews.llvm.org/D59165 llvm-svn: 355974
* Move ElaboratingDIEIterator into implementation file.Zachary Turner2019-03-122-71/+68
| | | | | | | | | | This is not used outside of the private implementation of the class, so hiding in the implementation file is a nice way of simplifying the external interface. Differential Revision: https://reviews.llvm.org/D59164 llvm-svn: 355973
* [lldb/thirdparty] Remove unneeded files, asked by Jonas.Davide Italiano2019-03-12123-14110/+0
| | | | llvm-svn: 355969
* [lldb-mi] Make this test more reliable. NFC.Davide Italiano2019-03-121-0/+6
| | | | | | Except that it will probably stop failing on and off on my machine. llvm-svn: 355968
* [third-party] Update pexpect to 4.6.Davide Italiano2019-03-12190-8661/+17969
| | | | | | | | | | | | Reviewers: labath, jdevlieghere Subscribers: lldb-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59159 llvm-svn: 355967
* Fix compiler warningJonas Devlieghere2019-03-121-13/+11
| | | | | | Fixes warning: comparison of integers of different signs. llvm-svn: 355963
* Rework how lldb warngs about kexts that failed to load in a Jason Molenda2019-03-121-8/+33
| | | | | | | | | | | | | | | | | | darwin kernel debug session. Originally, the kext name & uuid were emitted in the middle of the kext-loading period's. Last week I decided to try not printing any details about kexts that failed to load, only printing a summary of how many failed to load. This time I'm print different progress characters depending on whether the kext loaded or not ("-" for not), then at the end I will print a summary of how many kexts failed to load and a sorted list of the kexts with the bundle ID and the uuid. It's a lot more readable. <rdar://problem/48654569> llvm-svn: 355958
* Check the result of creating a node from __next_ in the std::list formatter.Jim Ingham2019-03-121-1/+3
| | | | | | | | | | | There's a single report of a crash coming from this current_sp being NULL. I don't have a repro case, and I couldn't get it to happen by hand-corrupting a list. We always get an error instead. So I don't have a test case. But checking for null is clearly right here. <rdar://problem/48503320> llvm-svn: 355957
* Re-enable this test, the underlying bug was fixed and the test now passes.Jim Ingham2019-03-121-1/+0
| | | | llvm-svn: 355956
* Fix the project for r355939 (ASTUtils.{h,c})Jim Ingham2019-03-121-0/+6
| | | | llvm-svn: 355951
* Correcting some comments in PdbIndex.cpp [NFC]Adrian McCarthy2019-03-121-5/+2
| | | | | | | | | | | | ICF can cause multiple symbols to start at the same virtual address. I plan to handle this shortly, but I wanted to correct the comment for now. Deleted an obsolete comment about adjusting the offset for the magic number at the beginning of the debug info stream. This adjustment is handled at a lower level now. llvm-svn: 355943
* [Reproducers] Add a test to ensure we can reuse the reproducer dir.Jonas Devlieghere2019-03-122-1/+11
| | | | | | | | Yesterday I noticed a reproducer test failing after making a local change. Removing the reproducer directory solved the issue. Add a test case that detects this. llvm-svn: 355941
* [Reproducers] Stop recording instead of deallocatingJonas Devlieghere2019-03-122-2/+10
| | | | | | | | | | | | | The command interpreter holds a pointer to a DataRecorder. After generating the reproducer, we deallocated all the DataRecorders, causing the command interpreter to hold a non-null reference to an invalid object. This patch changes the behavior of the command provider to stop the DataRecorders when a reproducer is generated, rather than deallocating them. llvm-svn: 355940
* Add ability to import std module into expression parser to improve C++ debuggingRaphael Isemann2019-03-1231-49/+1164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging. What happens in this patch is that we inject a `@import std` into our expression source code. We also modify our internal Clang instance for parsing this expression to work with modules and debug info at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The C++ include paths for building are extracted from the debug info, which means that this currently only works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths are currently specified by LLDB. I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific C include paths for them). With this patch we can now: * Build a libc++ as a module and import it into the expression parser. * Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`. What doesn't work (yet): * Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work. * Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't call yet any function that returns a non-trivial type. * Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches. Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille Reviewed By: aprantl Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D58125 llvm-svn: 355939
* [Reproducers] Support capturing a reproducer without an explicit path.Jonas Devlieghere2019-03-1211-30/+73
| | | | | | | | | | | | | | Tablegen doesn't support options that are both flags and take values as an argument. I noticed this when doing the tablegen rewrite, but forgot that that affected the reproducer --capture flag. This patch makes --capture a flag and adds --capture-path to specify a path for the reproducer. In reality I expect this to be mostly used for testing, but it could be useful nonetheless. Differential revision: https://reviews.llvm.org/D59238 llvm-svn: 355936
* Revert "[CMake] Avoid clang-tablegen-targets dependency when building sphinx ↵Stefan Granitz2019-03-121-1/+1
| | | | | | | | | docs (experimental)" This reverts commit 511066858d44101703d61eded9abf8caff0f9fe0. This turned out unnecessary to fix the bot. llvm-svn: 355931
* Correctly look up declarations in inline namespacesRaphael Isemann2019-03-1210-11/+108
| | | | | | | | | | | | | | | | | | Summary: This patch marks the inline namespaces from DWARF as inline and also ensures that looking up declarations now follows the lookup rules for inline namespaces. Reviewers: aprantl, shafik, serge-sans-paille Reviewed By: aprantl Subscribers: eraman, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D59198 llvm-svn: 355897
* [CMake] Avoid clang-tablegen-targets dependency when building sphinx docs ↵Jonas Devlieghere2019-03-121-1/+1
| | | | | | | | | | | | | (experimental) Proposal to fix bot http://lab.llvm.org:8011/builders/lldb-sphinx-docs/builds/1564/steps/cmake-configure/logs/stdio Patch by: Stefan Gränitz Differential revision: https://reviews.llvm.org/D59232 llvm-svn: 355887
* Add a case in SymbolFile{Native,}PDB::TranslateLanguage for SwiftNathan Lanza2019-03-112-0/+4
| | | | | | | | | | Summary: see above Reviewers: compnerd Differential Revision: https://reviews.llvm.org/D59230 llvm-svn: 355883
* [Reproducers] Make ReproducerInstrumentation a textual headerJonas Devlieghere2019-03-111-1/+2
| | | | | | | | The RECORD macro is context sensitive because it depends on the LLDB_GET_INSTRUMENTATION_DATA. This updates the modulemap to mark that header as textual. llvm-svn: 355879
* Rewrite comment to be clearerAlex Langford2019-03-111-1/+1
| | | | llvm-svn: 355875
OpenPOWER on IntegriCloud