summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't source local .lldbinit in the test suiteRaphael Isemann2019-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: As suggested by Pavel, we shouldn't let our tests parse the local .lldbinit to prevent random test failures due to changed settings. Fixes Minidump/Windows/Sigsegv/sigsegv.test (and probably others too). Reviewers: labath, serge-sans-paille Reviewed By: labath Subscribers: abidh, lldb-commits, zturner Tags: #lldb Differential Revision: https://reviews.llvm.org/D58235 llvm-svn: 354038
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-132-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
* [Reproducers] Integrate FileProvider with clangJonas Devlieghere2019-02-132-0/+10
| | | | | | | | | | This patch hooks up clang and lldb's reproducers functionality. It ensures that when capturing a reproducer, headers and modules imported through the expression parser are collected. Differential revision: https://reviews.llvm.org/D58076 llvm-svn: 353906
* [testsuite] Add a comment explaining what this test does.Davide Italiano2019-02-121-0/+1
| | | | llvm-svn: 353896
* [testsuite] Convert TestSingleQuote to lit.Davide Italiano2019-02-122-0/+8
| | | | | | Nothing crazy, this is pretty mechanical. llvm-svn: 353894
* [NativePDB] Process virtual bases in the correct orderAleksandr Urakov2019-02-122-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes virtual bases to be added in the correct order to the bases list. It is important because `VTableContext` (`MicrosoftVTableContext` in our case) uses then the order of virtual bases in the list to restore the virtual table indexes. These indexes are used then to resolve the layout of the virtual bases. We haven't enough information about offsets of virtual bases regarding to the object (moreover, in a common case we can't rely on such information, see the example here: https://reviews.llvm.org/D53506#1272306 ), but there should be enough information to restore the layout of the virtual bases from the indexes in runtime. After D53506 this information is used whenever possible, so there should be no problems with virtual bases' fields reading. Reviewers: zturner, rnk, stella.stamenova Subscribers: abidh, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56904 llvm-svn: 353806
* [build.py] Add `-fms-compatibility-version=19` to `build.py`Aleksandr Urakov2019-02-111-0/+1
| | | | | | | | | | | | | | | | | | | Summary: `clang-cl` can't compile tests containing `char16_t` and `char32_t` types without the MSVC compatibility option passed. This patch adds the option to the `clang-cl` call in the `build.py` script by default. Reviewers: zturner, labath, stella.stamenova, serge-sans-paille Reviewed By: labath Subscribers: lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D57809 llvm-svn: 353709
* Breakpad: auto-detect path style of file entriesPavel Labath2019-02-116-8/+18
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for auto-detection of path style to SymbolFileBreakpad (similar to how r351328 did the same for DWARF). We guess each file entry separately, as we have no idea which file came from which compile units (and different compile units can have different path styles). The breakpad generates should have already converted the paths to absolute ones, so this guess should be reasonable accurate, but as always with these kinds of things, it is hard to give guarantees about anything. In an attempt to bring some unity to the path guessing logic, I move the guessing logic from inside SymbolFileDWARF into the FileSpec class and have both symbol files use it to implent their desired behavior. Reviewers: clayborg, lemo, JDevlieghere Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D57895 llvm-svn: 353702
* [lldb] [lit] Fix finding lld-link when it is not in 'compiler dir'Michal Gorny2019-02-111-7/+5
| | | | | | | | | | | Fix the build helper to find lld-link via PATH lookup, rather than making a fragile assumption that it will be present in the 'compiler directory'. This fixes tests on Gentoo where clang and lld are installed in different directories. Differential Revision: https://reviews.llvm.org/D58001 llvm-svn: 353701
* [lldb] [test] Skip lldb-mi test if LLDB_DISABLE_PYTHON is usedMichal Gorny2019-02-113-1/+5
| | | | | | | | | | Skip running lldb-mi tests when Python support is disabled. This causes lldb-mi to unconditionally fail, and therefore all the relevant tests fail as well. Differential Revision: https://reviews.llvm.org/D58000 llvm-svn: 353700
* Revert "minidump: Add ability to attach (breakpad) symbol files to ↵Pavel Labath2019-02-113-30/+0
| | | | | | | | | | | placeholder modules" The commit has broken TestMiniDump.py on windows. Reverting while I investigate. This reverts r353677. llvm-svn: 353686
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-02-113-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 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: 353677
* Breakpad: temporarily XFAIL line-table testsPavel Labath2019-02-074-0/+8
| | | | | | | | | | | | The tests are failing on windows because the paths in the symbol file are parsed using the host path style. I'm working on a patch to have SymbolFileBreakpad auto-detect the correct path style (similar to dwarf r351328). I originally wanted to make this a part of the initial line-table patch, but then I simply forgot. llvm-svn: 353410
* SymbolFileBreakpad: Add line table supportPavel Labath2019-02-078-0/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch teaches SymbolFileBreakpad to parse the line information in breakpad files and present it to lldb. The trickiest question here was what kind of "compile units" to present to lldb, as there really isn't enough information in breakpad files to correctly reconstruct those. A couple of options were considered - have the entire file be one compile unit - have one compile unit for each FILE record - have one compile unit for each FUNC record The main drawback of the first approach is that all of the files would be considered "headers" by lldb, and so they wouldn't be searched if target.inline-breakpoint-strategy=never. The single compile unit would also be huge, and there isn't a good way to name it. The second approach will create mostly correct compile units for cpp files, but it will still be wrong for headers. However, the biggest drawback here seemed to be the fact that this can cause a compile unit to change mid-function (for example when a function from another file is inlined or another file is #included into a function). While I don't know of any specific thing that would break in this case, it does sound like a thing that we should avoid. In the end, we chose the third option, as it didn't seem to have any major disadvantages, though it was not ideal either. One disadvantage here is that this generates a large number of compile units, and there is still a question on how to name it. We chose to simply name it after the first line record in that function. This should be correct 99.99% of the time, though it can produce somewhat strange results if the very first line record comes from an #included file. Reviewers: clayborg, zturner, lemo, markmentovai Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56595 llvm-svn: 353404
* [testsuite] Convert a pexpect test to lit.Davide Italiano2019-02-062-0/+25
| | | | | | | | | | | | | | Summary: Reviewers: JDevlieghere, friss, zturner, labath, jingham, serge-sans-paille Subscribers: llvm-commits, lldb-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57840 llvm-svn: 353345
* [Reproducers] lldb-instr: tool to generate instrumentation macros.Jonas Devlieghere2019-02-064-1/+39
| | | | | | | | | | | | | | | | | This patch introduces a new tool called 'lldb-instr'. It automates the workflow of inserting LLDB_RECORD and LLDB_REGSITER macros for instrumentation. Because the tool won't be part of the build process, I didn't want to over-complicate it. SB_RECORD macros are inserted in place, while SB_REGISTER macros are printed to stdout, and have to be manually copied into the Registry's constructor. Additionally, the utility makes no attempt to properly format the inserted macros. Please use clang-format to format the changes after running the tool. Differential revision: https://reviews.llvm.org/D56822 llvm-svn: 353271
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-013-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | stored relative to VFRAME Summary: This patch makes LLDB able to retrieve proper values for function arguments and local variables stored in PDB relative to VFRAME register. Patch contains retrieval of corresponding FPO table entries from PDB and a generic translator from FPO programs to DWARF expressions to get correct VFRAME value. Patch also improves variables-locations.test and makes this test passable on x86. Patch By: leonid.mashinsky Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov Reviewed By: zturner Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D55122 llvm-svn: 352845
* [Reproducers] Add file providerJonas Devlieghere2019-01-294-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the file provider which is responsible for capturing files used by LLDB. When capturing a reproducer, we use a file collector that is very similar to the one used in clang. For every file that we touch, we add an entry with a mapping from its virtual to its real path. When we decide to generate a reproducer we copy over the files and their permission into to reproducer folder. When replaying a reproducer, we load the VFS mapping and instantiate a RedirectingFileSystem. The latter will transparently use the files available in the reproducer. I've tested this on two macOS machines with an artificial example. Still, it is very likely that I missed some places where we (still) use native file system calls. I'm hoping to flesh those out while testing with more advanced examples. However, I will fix those things in separate patches. Differential revision: https://reviews.llvm.org/D54617 llvm-svn: 352538
* [NativePDB] Fix lldb-x64-windows-ninja after r352464Aleksandr Urakov2019-01-292-8/+24
| | | | llvm-svn: 352478
* [NativePDB] Add basic support of methods recostruction in ASTAleksandr Urakov2019-01-292-0/+41
| | | | | | | | | | | | | | | | | | Summary: This patch adds the basic support of methods reconstruction by native PDB plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and LF_METHOD records), some things still remain unsolved: - mangled names retrieving; - support of template methods. Reviewers: zturner, labath, lemo, stella.stamenova Reviewed by: zturner Differential Revision: https://reviews.llvm.org/D56126 llvm-svn: 352464
* [CMake] Quick-Fix targets don't exist when building against LLVM ↵Stefan Granitz2019-01-281-3/+8
| | | | | | | | | | install-tree with LLDB_INCLUDE_TESTS=ON The issue came up during release testing for LLVM 8: https://bugs.llvm.org/show_bug.cgi?id=40443 Differential Revision: https://reviews.llvm.org/D57233 llvm-svn: 352382
* [lldb] Update shebang python2 -> pythonJonas Devlieghere2019-01-261-1/+1
| | | | llvm-svn: 352259
* Define the _fltused symbol in one lldb test as well, post-r352076.James Y Knight2019-01-251-0/+4
| | | | llvm-svn: 352159
* breakpad: Add FUNC records to the symtabPavel Labath2019-01-222-5/+8
| | | | | | | | | | | | | | | | | | | | This patch extends SymbolFileBreakpad::AddSymbols to include the symbols from the FUNC records too. These symbols come from the debug info and have a size associated with them, so they are given preference in case there is a PUBLIC record for the same address. To achieve this, I first pre-process the symbols into a temporary DenseMap, and then insert the uniqued symbols into the module's symtab. Reviewers: clayborg, lemo, zturner Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56590 llvm-svn: 351781
* [Test] Fix up tests affected by the new LLVM header.Jonas Devlieghere2019-01-224-4/+4
| | | | | | | | | The new LLVM header is one line shorter than the old one, which lead to some test failures. Ideally tests should rely on line numbers for breakpoints or output, but that's a different discussion. Hopefully this turns the bots green again. llvm-svn: 351779
* Fix test after AST dump output changeStephen Kelly2019-01-211-1/+1
| | | | llvm-svn: 351760
* Fix test after AST dump output changeStephen Kelly2019-01-211-1/+1
| | | | llvm-svn: 351733
* Fix test after AST dump output changeStephen Kelly2019-01-201-1/+1
| | | | llvm-svn: 351707
* Try to port tests to AST dump changesStephen Kelly2019-01-205-13/+10
| | | | llvm-svn: 351703
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [lit] Fix lldbtest formatJonas Devlieghere2019-01-171-2/+5
| | | | | | | The lldbtest format was incorrectly detecting XFAIL as FAIL because it was looking for the `FAIL:` substring in the dotest output. llvm-svn: 351497
* [lit] Make sure tests are actually skipped on darwin and windows.Davide Italiano2019-01-1710-10/+10
| | | | llvm-svn: 351486
* Recommit "Teach the default symbol vendor to respect ↵Pavel Labath2019-01-173-0/+73
| | | | | | | | | | | | | | module.GetSymbolFileFileSpec()" This reapplies commit r351330, which was reverted due to a failing test on macos. The failure was because the SymbolVendor used on MacOS was stricter than the default (or ELF) symbol vendor, and rejected the symbol file because it's UUID did not match the object file. This version of the patch adds a uuid load command to the test macho file to make sure the UUIDs match. llvm-svn: 351447
* Recommit "Add a verbose mode to "image dump line-table" and use it to write ↵Pavel Labath2019-01-171-0/+75
| | | | | | | | | | | a .debug_line test" This reapplies r350802, which was reverted because of issues with parsing posix-style paths on windows hosts (and vice-versa). These have since been fixed in r351328, and lldb should now recognise the path style used in a dwarf compile unit correctly. llvm-svn: 351435
* Change TypeSystem::GetBitSize() to return an optional result.Adrian Prantl2019-01-161-4/+4
| | | | | | | | | | | | This patch changes the behavior when printing C++ function references: where we previously would get a <could not determine size>, there is now a <no summary available>. It's not clear to me whether this is a bug or an omission, but it's one step further than LLDB previously got. Differential Revision: https://reviews.llvm.org/D56798 llvm-svn: 351376
* Fix dir-separator-no-comp-dir-relative-name.s test added in r351328Pavel Labath2019-01-161-6/+7
| | | | | | | | | In this test we have deliberately removed all information which may hint at the correct path style, so we cannot assert that lldb uses a particular style. Instead, we should just check that it does something vaguely reasonable. llvm-svn: 351359
* Revert "Teach the default symbol vendor to respect ↵Pavel Labath2019-01-163-70/+0
| | | | | | | | module.GetSymbolFileFileSpec()" This reverts commit r351330 due to failures on MacOS bots. llvm-svn: 351353
* Teach the default symbol vendor to respect module.GetSymbolFileFileSpec()Pavel Labath2019-01-163-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adding a breakpad symbol file to an existing MachO module with "target symbols add" currently works only if one's host platform is a mac. This is because SymbolVendorMacOSX (which is the one responsible for loading symbols for MachO files) is conditionally compiled for the mac platform. While we will sooner or later have a special symbol vendor for breakpad files (to enable more advanced searching), and so this flow could be made to work through that, it's not clear to me whether this should be a requirement for the "target symbols add" flow to work. After all, since the user has explicitly specified the symbol file to use, the symbol vendor plugin's job is pretty much done. This patch teaches the default symbol vendor to respect module's symbol file spec, and load the symbol from that file if it is specified (and no plugin requests any special handling). Reviewers: clayborg, zturner, lemo Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56589 llvm-svn: 351330
* DWARF: Add some support for non-native directory separatorsPavel Labath2019-01-167-0/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we opened a file which was produced on system with different path syntax, we would parse the paths from the debug info incorrectly. The reason for that is that we would parse the paths as they were native. For example this meant that on linux we would treat the entire windows path as a single file name with no directory component, and then we would concatenate that with the single directory component from the DW_AT_comp_dir attribute. When parsing posix paths on windows, we would at least get the directory separators right, but we still would treat the posix paths as relative, and concatenate them where we shouldn't. This patch attempts to remedy this by guessing the path syntax used in each compile unit. (Unfortunately, there is no info in DWARF which would give the definitive path style used by the produces, so guessing is all we can do.) Currently, this guessing is based on the DW_AT_comp_dir attribute of the compile unit, but this can be refined later if needed (for example, the DW_AT_name of the compile unit may also contain some useful info). This style is then used when parsing the line table of that compile unit. This patch is sufficient to make the line tables come out right, and enable breakpoint setting by file name work correctly. Setting a breakpoint by full path still has some kinks (specifically, using a windows-style full path will not work on linux because the path will be parsed as a linux path), but this will require larger changes in how breakpoint setting works. Reviewers: clayborg, zturner, JDevlieghere Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D56543 llvm-svn: 351328
* [CMake] LLVM exports utility targets since r350959, so we can use them ↵Stefan Granitz2019-01-141-8/+3
| | | | | | without standalone-checks now llvm-svn: 351037
* Attempt to fix PDB tests broken by r350924Pavel Labath2019-01-116-6/+6
| | | | | | | The patch added the symbol plugin name to the lldb-test output. Update the tests to account for that. llvm-svn: 350947
* [CMake] Remove dead code and outdated commentsStefan Granitz2019-01-111-17/+0
| | | | | | | | | | | | | | Summary: All of these changes are NOPs. Reviewers: stella.stamenova, labath, JDevlieghere Reviewed By: stella.stamenova Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56609 llvm-svn: 350937
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-113-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds the glue code necessary to integrate the SymbolFileBreakpad into the plugin system. Most of the methods are stubbed out. The only method implemented method is AddSymbols, which parses the PUBLIC "section" of the breakpad "object file", and fills out the Module's symtab. To enable testing this, I've made two additional changes: - dump Symtab from the SymbolVendor class. The symtab was already being dumped as a part of the object file dump, but that happened before symbol vendor kicked in, so it did not reflect any symbols added there. - add ability to explicitly specify the external symbol file in lldb-test (so that the object file could be linked with the breakpad symbol file). To make things simpler, I've changed lldb-test from consuming multiple inputs (and dumping their symbols) to having it just process a single file per invocation. This was not a problem since everyone was using it that way already. Reviewers: clayborg, zturner, lemo, markmentovai, amccarth Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56173 llvm-svn: 350924
* ELF: Fix base address computation code for files generated by yaml2objPavel Labath2019-01-111-0/+34
| | | | | | | | | | | | | | | | | | | | | The code was assuming that the elf file will have a PT_LOAD segment starting from the first byte of the file. While this is true for files generated by most linkers (it's a way of saving space), it is not a requirement. And files not satisfying this constraint can still be perfectly executable. yaml2obj is one of the tools which produces files like this. This patch relaxes the check in ObjectFileELF to take the address of the first PT_LOAD segment as the base address of the object (instead of the one with the offset 0). Since the PT_LOAD segments are supposed to be sorted according to the VM address, this entry will also be the one with the lowest VM address. If we ever run into files which don't have the PT_LOAD segments sorted, we can easily change this code to return the lowest VM address as the base address (if that is the correct thing to do for these files). llvm-svn: 350923
* [NativePDB] Add support for parsing typedef records.Zachary Turner2019-01-101-0/+71
| | | | | | | | | | | | | | | | | | | | Typedefs are represented as S_UDT records in the globals stream. This creates a strange situation where "types" are actually represented as "symbols", so they need special handling. In order to test this, we don't just use lldb and print out some variables causing the AST to get created, because variables whose type is a typedef will have debug info referencing the original type, not the typedef. So we use lldb-test instead which will parse all debug info in the entire file. This exposed some problems with lldb-test and the native reader, mainly that certain types of obscure symbols which we can find when iterating every single record would trigger crashes. These have been fixed as well so that lldb-test can be used to test this functionality. Differential Revision: https://reviews.llvm.org/D56461 llvm-svn: 350888
* Revert "Add a verbose mode to "image dump line-table" and use it to write a ↵Pavel Labath2019-01-101-75/+0
| | | | | | | | | | | | | .debug_line test" This reverts commit r350802 because the test fails on windows. This happens because we treat the paths as windows paths even though they have linux path separators in the asm file. That results in wrong paths being computed (\tmp\tmp\a.c instead of /tmp/a.c). Reverting until I can figure out what to do with this. llvm-svn: 350810
* PECOFF: Fix section name computationPavel Labath2019-01-101-0/+52
| | | | | | | | | | | | | | | | | | If a section name is exactly 8 bytes long (or has been truncated to 8 bytes), it will not contain the terminating nul character. This means reading the name as a c string will pick up random data following the name field (which happens to be the section vm size). This fixes the name computation to avoid out-of-bounds access and adds a test. Reviewers: zturner, stella.stamenova Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56124 llvm-svn: 350809
* Implement ObjectFileELF::GetBaseAddressPavel Labath2019-01-102-2/+31
| | | | | | | | | Summary: The concept of a base address was already present in the implementation (it's needed for computing section load addresses properly), but it was never exposed through this function. This fixes that. llvm-svn: 350804
* Add a verbose mode to "image dump line-table" and use it to write a ↵Pavel Labath2019-01-101-0/+75
| | | | | | | | | | | | | | | | | | | | | | .debug_line test Summary: The motivation for this is being able to write tests for the upcoming breakpad line table parser, but this could be useful for testing the low-level workings of any line table format. Or simply for viewing the line table information with more detail (the brief format doesn't include any of the flags for end_of_prologue and similar). I've also removed the load_addresses argument from the DumpCompileUnitLineTable function, as it wasn't being used anywhere. Reviewers: clayborg, zturner Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56315 llvm-svn: 350802
* Write PDB/variables.test to be more robust.Zachary Turner2019-01-091-50/+58
| | | | | | | | | | | | | | | | | | | CHECK-DAG can't really be mixed with CHECK-NEXT statements because each non DAG check sets a new search-origin for following CHECK-DAG statements. This was passing by coincidence before, but a benign change in the way we process symbols caused the order of the output to be different, which triggered this test to fail. This change makes the test resilient against ordering problems by running a separate invocation of FileCheck for each function that we want to test. Note that with the Native PDB reader, we have full control over the ordering that symbols are processed in, so we don't have to worry about different machines returning things in different orders due to different DIA SDK versions. llvm-svn: 350773
OpenPOWER on IntegriCloud