summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
...
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-5/+8
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-8/+5
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-5/+8
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-211-2/+16
| | | | | | | | | | | | | | | This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
* Recommit "Minidump/Windows: Fix module lookup""Pavel Labath2019-08-213-0/+68
| | | | | | | | | | | | | | | | | | | | | | | This recommits r368416, which was reverted in r368838 because of test failures under ASAN. These have been dealt with by llvm r369370. The original commit message was: When opening a minidump, we were failing to find an executable because we were searching for i386-unknown-windows, whereas we recognize the pe/coff files as i386-pc-windows. This fixes the triple computation code in the minidump parser to match pe/coff, and adds an appropriate test. NB: I'm not sure setting the vendor to "pc" is really correct for arm(64) windows, but right now that seems to match what we do in the pe/coff case (ArchSpec.cpp:935). Reviewers: clayborg, amccarth Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D65955 llvm-svn: 369523
* Make the FindTypes(std::vector<CompilerContext>, ...) API testable in lldb-testAdrian Prantl2019-08-202-1/+36
| | | | | | | | | | | | | This adds a -compiler-context=<...> option to lldb-test that trakes a comma-separated string that is a list of kind/name pairs and translates it into a std::vector<CompilerContext>, a CompilerContext being a pair of context-kind and name. Differential Revision: https://reviews.llvm.org/D66453 <rdar://problem/54471165> llvm-svn: 369407
* Revert "Minidump/Windows: Fix module lookup"Pavel Labath2019-08-143-68/+0
| | | | | | | | | | | Although there is nothing wrong with this patch, the test added here uncovers a problem in other parts of the code which cause the test to fail when running under asan. Reverting the patch until I can fix the underlying issue(s). This reverts commit r368416. llvm-svn: 368838
* Minidump/Windows: Fix module lookupPavel Labath2019-08-093-0/+68
| | | | | | | | | | | | | | | | | | | | Summary: When opening a minidump, we were failing to find an executable because we were searching for i386-unknown-windows, whereas we recognize the pe/coff files as i386-pc-windows. This fixes the triple computation code in the minidump parser to match pe/coff, and adds an appropriate test. NB: I'm not sure setting the vendor to "pc" is really correct for arm(64) windows, but right now that seems to match what we do in the pe/coff case (ArchSpec.cpp:935). Reviewers: clayborg, amccarth Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D65955 llvm-svn: 368416
* ObjectFileELF: Convert a unit test to a lit testPavel Labath2019-08-081-0/+93
| | | | | | It is much easier to test this functionality via lldb-test. llvm-svn: 368289
* Add support for deterministically linked binaries on macOS to lldb.Nico Weber2019-08-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When ld64 links a binary deterministically using the flag ZERO_AR_DATE, it sets a timestamp of 0 for N_OSO members in the symtab section, rather than the usual last modified date of the object file. Prior to this patch, lldb would compare the timestamp from the N_OSO member against the last modified date of the object file, and skip loading the object file if there was a mismatch. This patch updates the logic to ignore the timestamp check if the N_OSO member has timestamp 0. The original logic was added in https://reviews.llvm.org/rL181631 as a safety check to avoid problems when debugging if the object file was out of date. This was prior to the introduction of deterministic build in ld64. lld still doesn't support deterministic build. Other code in llvm already relies on and uses the assumption that a timestamp of 0 means deterministic build. For example, commit 9ccfddc39d4d27f9b16fcc72ab30d483151d6d08 adds similar timestamp checking logic to dsymutil, but special cases timestamp 0. Likewise, commit 0d1bb79a0413f221432a7b1d0d2d10c84c4bbb99 adds a long comment describing deterministic archive, which mostly uses timestamp 0 for determinism. Patch from Erik Chen <erikchen@chromium.org>! Differential Revision: https://reviews.llvm.org/D65826 llvm-svn: 368199
* [Driver] Expand the executable path in the target create outputJonas Devlieghere2019-08-071-0/+7
| | | | | | | | | | | | | | | | | | Resolve the path in the target create output. This is nice when passing relative paths to the lldb command line driver. $ lldb ./binary (lldb) target create "./binary" Current executable set to '/absolute/path/to/binary' (x86_64). This change only affects the target create output and does not change the debugger's behavior. It doesn't resolve symbolic links so it won't cause confusing when debugging something like clang++ that's symlinked to clang. Differential revision: https://reviews.llvm.org/D65611 llvm-svn: 368182
* A more robust way of testing debug_line parser near the end of modulePavel Labath2019-08-072-3/+28
| | | | | | | | | | | | | | | | | | Summary: While removing -z separate-code makes lld produce place the code at the end of a segment right now, it's possible that future changes to the linker will change that, thereby removing the coverage for the changes in r367983. This patch adds a linker script to one of the line table tests, which ensures that the code (and its line table) will be placed at the very end of a module. Reviewers: MaskRay Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65789 llvm-svn: 368154
* ObjectFileELF: permit thread-local sections with overlapping file addressesPavel Labath2019-08-062-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In an attempt to make file-address-based lookups more predictable, in D55998 we started ignoring sections which would result in file address overlaps. It turns out this was too aggressive because thread-local sections typically will have file addresses which apear to overlap regular data/code. This does not cause a problem at runtime because thread-local sections are loaded into memory using special logic, but it can cause problems for lldb when trying to lookup objects by their file address. This patch changes ObjectFileELF to permit thread-local sections to overlap regular ones by essentially giving them a separate address space. It also makes them more symmetrical to regular sections by creating container sections from PT_TLS segments. Simultaneously, the patch changes the regular file address lookup logic to ignore sections with the thread-specific bit set. I believe this is what the users looking up file addresses would typically expect, as looking up thread-local data generally requires more complex logic (e.g. DWARF has a special opcode for that). Reviewers: clayborg, jingham, MaskRay Subscribers: emaste, aprantl, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D65282 llvm-svn: 368010
* SymbolVendorELF: Perform build-id lookup even without a debug linkPavel Labath2019-08-062-1/+33
| | | | | | | | | | | | | | | | | | | | | | Summary: The debug link and build-id lookups are two independent ways one can search for a separate symbol file. However, our implementation in SymbolVendorELF was tying the two together and refusing to look up the symbol file based on a build id if the file did not contain a debug link. This patch makes it possible to search for the symbol file with just one of the two methods available. To demonstrate, I split the build-id-case test into two, so that we test the search using both methods. Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap Subscribers: emaste, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65561 llvm-svn: 367994
* Fix line table resolution near the end of a sectionPavel Labath2019-08-065-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lld r367537 changed the way the linker organizes sections and segments. This exposed an lldb bug and caused some tests to fail. In all of the failing tests the root cause was the same -- when we were trying to resolve the last address in the line_table section, we failed because it pointed past the end of the section. This patch changes the line table address resolution code to back up the address by one for end-of-sequence entries. This ensures the address still points inside a section/module even if the line table sequence ends at the very end of a section. It also reverts the linker flags which were added to the failing tests to restore previous behavior. Reviewers: clayborg, jingham Subscribers: mgorny, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65647 llvm-svn: 367983
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367850
* Fix PDB tests after r367820Pavel Labath2019-08-056-6/+6
| | | | | | | | | | | The commit changed Module dumping code to call SymbolFile::Dump directly, which meant that we were no longer showing the plugin name in the output (as that was done in the SymbolVendor). This adds the plugin name printing code to the SymbolFile dump method, and tweak the assertions in the PDB tests to match it correctly. llvm-svn: 367835
* Use rip-relative addressing in asm testJoseph Tremoulet2019-08-021-1/+1
| | | | | | The absolute form is an error when targeting Darwin. llvm-svn: 367706
* Fix PC adjustment in StackFrame::GetSymbolContextJoseph Tremoulet2019-08-022-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames. Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places. Reviewers: jasonmolenda, clayborg, jfb Reviewed By: jasonmolenda Subscribers: labath, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64993 llvm-svn: 367691
* Fix `skipIfSanitized` decorator on macOSJonas Devlieghere2019-08-011-12/+10
| | | | | | | | | | | For security reasons, DYLD_INSERT_LIBRARIES is not propagated to a child process. This breaks the skipIfSanitized decorator, which checks for the environment variable being set. Instead, always set the ASAN_OPTIONS and make the decorator check for that. Differential revision: https://reviews.llvm.org/D65594 llvm-svn: 367595
* 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
* [Reproducers] Force replay in synchronous mode.Jonas Devlieghere2019-07-311-0/+13
| | | | | | | | | 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
* [lldb] Increase testsuite packet-timeout 5secs -> 1minJan Kratochvil2019-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [AIX][lit] Don't depend on psutil on AIXDavid Tenty2019-07-241-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: On AIX psutil can run into problems with permissions to read the process tree, which causes problems for python timeout tests which need to kill off a test and it's children. This patch adds a workaround by invoking shell via subprocess and using a platform specific option to ps to list all the descendant processes so we can kill them. We add some checks so lit can tell whether timeout tests are supported with out exposing whether we are utilizing the psutil implementation or the alternative. Reviewers: hubert.reinterpretcast, andusy, davide, delcypher Reviewed By: delcypher Subscribers: davide, delcypher, christof, lldb-commits, libcxx-commits, llvm-commits Tags: #lldb, #libc, #llvm Differential Revision: https://reviews.llvm.org/D64251 llvm-svn: 366912
* [lldb][NFC] Cleanup mentions and code related to lldb-miRaphael Isemann2019-07-191-9/+0
| | | | | | | | | | | | | | | | Summary: lldb-mi has been removed, but there are still a bunch of references in the code base. This patch removes all of them. Reviewers: JDevlieghere, jfb Reviewed By: JDevlieghere Subscribers: dexonsmith, ki.stfu, mgorny, abidh, jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64992 llvm-svn: 366590
* [LLDB] Remove lldb-miJonas Devlieghere2019-07-1836-563/+0
| | | | | | | | | | | | | | As discussed on the mailing list [1], this patch removes the lldb-mi tool and its tests from the LLDB repository. We moved lldb-mi into a separate repository on GitHub [2] for downstream users or maintainers to build and package. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-July/015103.html [2] https://github.com/lldb-tools/lldb-mi Differential revision: https://reviews.llvm.org/D64255 llvm-svn: 366465
* ObjectFileELF: Add support for gnu-style compressed sectionsPavel Labath2019-07-102-1/+26
| | | | | | | | | With this style, a compressed section is indicated by a "z" in the section name, instead of a section header flag. This patch consists of two small tweaks: - use an llvm Decompressor method in order to properly detect compressed sections - make sure we recognise .zdebug_info (and friends) when classifying section types. llvm-svn: 365654
* [DWARF] Add one more type unit testPavel Labath2019-07-021-0/+37
| | | | | | | This test passes already, but it seems interesting to test that we can jump between type units in different dwo files nonetheless. llvm-svn: 364890
* Fix lookup of symbols at the same address with no size vs. sizeJan Kratochvil2019-07-012-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30): PASS: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325 frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243 frame #7: 0x000000000040106e a.out`_start + 46 vs. FAIL - unrecognized abort() function: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325 frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243 frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46 The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28). It is due to: Symbol table '.dynsym' contains 2361 entries: Valu e Size Type Bind Vis Name 0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely 000000000002276e 548 FUNC GLOBAL DEFAULT abort 000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5 000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort 0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely Differential Revision: https://reviews.llvm.org/D63540 llvm-svn: 364773
* DWARF: Add support for type units+split dwarf comboPavel Labath2019-06-253-10/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With the last round of refactors, supporting type units in dwo files becomes almost trivial. This patch contains a couple of small fixes, which taken as a whole make type units work in the split dwarf scenario (both DWARF4 and DWARF5): - DWARFContext: make sure we actually read the debug_types.dwo section - DWARFUnit: set string offsets base on all units in the dwo file, not just the main CU - ManualDWARFIndex: index all units in the file - SymbolFileDWARFDwo: Search for the single compile unit in the file, as we can no longer assume it will be the first one The last part makes it obvious that there is still some work to be done here, namely that we do not support dwo files with multiple compile units. That is something that should be easier after the DIERef refactors, but it still requires more work. Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as well as a test that checks we behave reasonably in the presence of dwo files with multiple CUs. Reviewers: clayborg, JDevlieghere, aprantl Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63643 llvm-svn: 364274
* Reapply "Fix a crash in option parsing."Adrian Prantl2019-06-252-0/+4
| | | | | | | | with an additional read-out-of-bounds bugfix applied. Differential Revision: https://reviews.llvm.org/D63110 llvm-svn: 364260
* [lit] Deduplicate logic in toolchain.pyJonas Devlieghere2019-06-211-6/+4
| | | | | | No need to compute the path of lit-lldb-init twice. llvm-svn: 364113
* [lit] Make lit-lldb-init configurable by CMakeJonas Devlieghere2019-06-213-2/+6
| | | | | | | | | | This makes the `lit-lldb-init` file configurable by CMake. This matters to us downstream in Swift, where we want to set environment variables with the `env` command for every test. Differential revision: https://reviews.llvm.org/D63679 llvm-svn: 364112
* DWARF: Add "dwo_num" field to the DIERef classPavel Labath2019-06-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When dwo support was introduced, it used a trick where debug info entries were referenced by the offset of the compile unit in the main file, but the die offset was relative to the dwo file. Although there was some elegance to it, this representation was starting to reach its breaking point: - the fact that the skeleton compile unit owned the DWO file meant that it was impossible (or at least hard and unintuitive) to support DWO files containing more than one compile unit. These kinds of files are produced by LTO for example. - it made it impossible to reference any DIEs in the skeleton compile unit (although the skeleton units are generally empty, clang still puts some info into them with -fsplit-dwarf-inlining). - (current motivation) it made it very hard to support type units placed in DWO files, as type units don't have any skeleton units which could be referenced in the main file This patch addresses this problem by introducing an new "dwo_num" field to the DIERef class, whose purpose is to identify the dwo file. It's kind of similar to the dwo_id field in DWARF5 unit headers, but while this is a 64bit hash whose main purpose is to catch file mismatches, this is just a smaller integer used to indentify a loaded dwo file. Currently, this is based on the index of the skeleton compile unit which owns the dwo file, but it is intended to be eventually independent of that (to support the LTO use case). Simultaneously the cu_offset is dropped to conserve space, as it is no longer necessary. This means we can remove the "BaseObjectOffset" field from the DWARFUnit class. It also means we can remove some of the workarounds put in place to support the skeleton-unit+dwo-die combo. More work is needed to remove all of them, which is out of scope of this patch. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63428 llvm-svn: 364009
* Revert "Fix a crash in option parsing."Davide Italiano2019-06-202-3/+0
| | | | | | This fails on the bots around 1/10 of the time. llvm-svn: 363999
* [Reproducers] Make reproducer relocatableJonas Devlieghere2019-06-181-0/+7
| | | | | | | | | | | | | | Before this patch, reproducers weren't relocatable. The reproducer contained hard coded paths in the VFS mapping, as well in the yaml file listing the different input files for the command interpreter. This patch changes that: - Use relative paths for the DataCollector. - Use an overlay prefix for the FileCollector. Differential revision: https://reviews.llvm.org/D63467 llvm-svn: 363697
* [lldb] [test] Extend D55859 symbols.enable-external-lookup=false for more ↵Jan Kratochvil2019-06-1710-0/+30
| | | | | | | | | | | | | | | | | | | | | | testcases D55859 <https://reviews.llvm.org/D55859> has no effect for some of the testcases so this patch extends it even for (all?) other testcases known to me. LLDB was failing when LLDB prints errors reading system debug infos (`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases should not be affected by system debug infos. `lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is using only SB API which does not expose `ModuleList` so I had to call `HandleCommand()` there. `lldb-test.cpp` could also use `HandleCommand` and then there would be no need for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner with API and not on based on text commands. Differential Revision: https://reviews.llvm.org/D63339 llvm-svn: 363567
* DWARF: Don't create lldb CompileUnits for DWARF type unitsPavel Labath2019-06-132-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Type units don't represent actual compilations and a lot of the operations that we do with lldb compile units (getting their line tables, variables, etc.) don't make sense for them. There is also a lot more of them (sometimes over 100x), so making them more lightweight pays off. The main change in this patch is that we stop creating lldb CompileUnits for DWARF type units. The trickiest part here is that the SymbolFile interface requires that we assign consecutive sequence IDs to the compile units we create. As DWARF type and compile units can come in any order (in v5), this means we can no longer use 1-1 mapping between DWARF and lldb compile units. Instead I build a translation table between the two indices. To avoid pessimizing the case where there are no type units, I build the translation table only in case we have at least one type unit. Additionaly, I also tried to strenghted type safete by replacing DWARFUnit with DWARFCompileUnit where applicable. Though that was not stricly necessary, I found it a good way to ensure that the transformations I am doing here make sense. In the places where I was changing the function signatures, and where it was obvious that the objects being handled were not null, I also replaced pointers with references. There shouldn't be any major functional change with this patch. The only change I observed is that now the types in the type units will not be parsed when one calls Module::ParseAllDebugSymbols, unless they are referenced from other compile units. This makes sense, given how ParseAllDebugSymbols is implemented (it iterates over all compile units), and it only matters for one hand-writted test where I did not bother to reference the types from the compile units (which I now do). Reviewers: clayborg, JDevlieghere, aprantl Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D63005 llvm-svn: 363250
* [Reproducers] Include lldb version in the reproducer rootJonas Devlieghere2019-06-131-0/+3
| | | | | | | | | | | Generally, reproducers are rev-locked to the version of LLDB, so it's valuable to have the LLDB version in the reproducer. For now I just want the information to be present, without enforcing it, but I envision emitting a warning during replay in the future. Differential revision: https://reviews.llvm.org/D63229 llvm-svn: 363225
* Recognise debug_types.dwo as a debug info sectionPavel Labath2019-06-121-0/+7
| | | | | | This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
* DWARF: Share line tables of type unitsPavel Labath2019-06-122-0/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch creates a cache of file lists in line tables referenced by type units. This cache is used to avoid parsing a line table twice (since a file list will generally be shared by many type units). It also sets things up in a way that parsing of DW_AT_decl_file attributes will keep working even when we stop creating lldb compile units for dwarf type units, but it stops short of actually doing that. This means that the request for files now go directly to SymbolFileDWARF instead of being routed there indirectly via the lldb_private::CompileUnit class. As a result of this, a number of occurences of SymbolContext variables in DWARFASTParserClang have become unused, so I remove them. This patch reduces the number of times a file list is being parsed, but the situation is still suboptimal, as the parsed list is being copied multiple times. This will be fixed when we stop creating CompileUnits for DWARF type units. Reviewers: clayborg, aprantl, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D62894 llvm-svn: 363143
* Fix a crash in option parsing.Adrian Prantl2019-06-112-0/+3
| | | | | | | | | | | The call to getopt_long didn't handle the case where the *last* option had an argument missing. <rdar://problem/51231882> Differential Revision: https://reviews.llvm.org/D63110 llvm-svn: 363101
* Breakpad: Add support for the arm64e "architecture"Pavel Labath2019-06-102-0/+6
| | | | llvm-svn: 362960
* Add "REQUIRES: x86" to DWARF assembly testsPavel Labath2019-06-1017-10/+26
| | | | | | | These tests don't require an x86 host, but they do require that we build the x86 llvm target. llvm-svn: 362948
* [CMake] Add special case for processing LLDB_DOTEST_ARGSStefan Granitz2019-06-071-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow to run the test suite when building LLDB Standalone with Xcode against a provided LLVM build-tree that used a single-configuration generator like Ninja. So far both test drivers, lit-based `check-lldb` as well as `lldb-dotest`, were looking for test dependencies (clang/dsymutil/etc.) in a subdirectory with the configuration name (Debug/Release/etc.). It was implicitly assuming that both, LLDB and the provided LLVM used the same generator. In practice, however, the opposite is quite common: build the dependencies with Ninja and LLDB with Xcode for development*. With this patch it becomes the default. (* In fact, it turned out that the Xcode<->Xcode variant didn't even build out of the box. It's fixed since D62879) Once this is sound, I'm planning the following steps: * add stage to the [lldb-cmake-standalone bot](http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/) to build and test it * update `Building LLDB with Xcode` section in the docs * bring the same mechanism to swift-lldb * fade out the manually maintained Xcode project On macOS build and test like this: ``` $ git clone https://github.com/llvm/llvm-project.git /path/to/llvm-project $ cd /path/to/lldb-dev-deps $ cmake -GNinja -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi" /path/to/llvm-project/llvm $ ninja $ cd /path/to/lldb-dev-xcode $ cmake -GXcode -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLDB_BUILD_FRAMEWORK=Off -DLLVM_DIR=/path/to/lldb-dev-deps/lib/cmake/llvm -DClang_DIR=/path/to/lldb-dev-deps/lib/cmake/clang /path/to/llvm-project/lldb $ xcodebuild -configuration Debug -target check-lldb $ xcodebuild -configuration Debug -target lldb-dotest $ ./Debug/bin/lldb-dotest ``` Reviewers: JDevlieghere, jingham, xiaobai, stella.stamenova, labath Reviewed By: stella.stamenova Subscribers: labath, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62859 llvm-svn: 362803
* Ignore DIEs in the skeleton unit in a DWO scenarioPavel Labath2019-06-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r362103 exposed a bug, where we could read incorrect data if a skeleton unit contained more than the single unit DIE. Clang emits these kinds of units with -fsplit-dwarf-inlining (which is also the default). Changing lldb to handle these DIEs is nontrivial, as we'd have to change the UID encoding logic to be able to reference these DIEs, and fix up various places which are assuming that all DIEs come from the separate compile unit. However, it turns out this is not necessary, as the DWO unit contains all the information that the skeleton unit does. So, this patch just skips parsing the extra DIEs if we have successfully found the DWO file. This enforces the invariant that the rest of the code is already operating under. This patch fixes a couple of existing tests, but I've also included a simpler test which does not depend on execution of binaries, and would have helped us in catching this sooner. Reviewers: clayborg, JDevlieghere, aprantl Subscribers: probinson, dblaikie, lldb-commits Differential Revision: https://reviews.llvm.org/D62852 llvm-svn: 362586
* [FormatEntity] Ignore ASCII escape sequences when colors are disabled.Jonas Devlieghere2019-05-313-0/+26
| | | | | | | | | This patch makes the FormatEntity honor the debugger's color settings by not inserting ASCII escape sequences when colors are disabled. Differential revision: https://reviews.llvm.org/D62714 llvm-svn: 362240
OpenPOWER on IntegriCloud