summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* Recommit "Teach the default symbol vendor to respect ↵Pavel Labath2019-01-174-5/+85
| | | | | | | | | | | | | | 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-172-4/+119
| | | | | | | | | | | 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
* XFAIL test on WindowsAdrian Prantl2019-01-161-1/+2
| | | | | | http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/677/steps/test/logs/stdio llvm-svn: 351385
* Change TypeSystem::GetBitSize() to return an optional result.Adrian Prantl2019-01-169-34/+86
| | | | | | | | | | | | 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-164-82/+5
| | | | | | | | module.GetSymbolFileFileSpec()" This reverts commit r351330 due to failures on MacOS bots. llvm-svn: 351353
* TestClangASTContext: Rewrite an if-else chain into a switchPavel Labath2019-01-161-3/+11
| | | | | | | This avoids the "ambiguous else" warning, which comes from within the EXPECT_TRUE macro. llvm-svn: 351331
* Teach the default symbol vendor to respect module.GetSymbolFileFileSpec()Pavel Labath2019-01-164-5/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1615-77/+382
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Simplify Value::GetValueByteSize()"Pavel Labath2019-01-161-15/+19
| | | | | | | This reverts commit r351250 because it breaks the SymbolFile/NativePDB/function-types-builtins.cpp. llvm-svn: 351327
* [lldb] - Fix crash when listing the history with the key up.George Rimar2019-01-161-1/+1
| | | | | | | | | | | | This is https://bugs.llvm.org/show_bug.cgi?id=40112, Currently, lldb crashes after pressing the up arrow key when listing the history for expressions. The patch fixes the mistype that was a reason. Differential revision: https://reviews.llvm.org/D56014 llvm-svn: 351313
* [lldb-mi] Remove use of dialog boxAlex Langford2019-01-163-24/+0
| | | | | | | | | | | | | | | | Summary: This really is only implemented on Windows, and it requires us to pull in User32. This was only useful when debugging on lldb-mi on Windows, and there doesn't seem to be a good reason why using a dialog box is better than what exists for other platforms. Reviewers: zturner, jingham, compnerd Subscribers: ki.stfu Differential Revision: https://reviews.llvm.org/D56755 llvm-svn: 351276
* Remove redundant check.Adrian Prantl2019-01-151-5/+3
| | | | llvm-svn: 351274
* Simplify code by using Optional::getValueOr()Adrian Prantl2019-01-154-10/+5
| | | | llvm-svn: 351264
* [debugserver][CMake] Remove commented out lineAlex Langford2019-01-151-1/+0
| | | | | | | | This has been commented out since rL300111 (commit d742d081f3a1e7412cc609765139ba32d597ac15). Looks like it was committed as a commented out line, so I'm removing it. llvm-svn: 351263
* Simplify Value::GetValueByteSize()Adrian Prantl2019-01-151-19/+15
| | | | llvm-svn: 351250
* Simplify codeAdrian Prantl2019-01-151-17/+21
| | | | llvm-svn: 351244
* Add Doxygen comments.Adrian Prantl2019-01-151-0/+2
| | | | llvm-svn: 351243
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-1534-94/+128
| | | | | | This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
* Silence compiler warningsAdrian Prantl2019-01-158-8/+8
| | | | llvm-svn: 351215
* Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl2019-01-1536-533/+698
| | | | | | | | | | | | | | | | | | | | | | | The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
* [LLDB] Remove the unused variable oso_dwarf.David L. Jones2019-01-151-1/+0
| | | | | | Patch by Ali Tamur! (tamur@google.com) llvm-svn: 351158
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-1430-169/+111
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [SymbolFile] Remove the SymbolContext parameter from FindNamespace.Zachary Turner2019-01-1415-43/+20
| | | | | | | | | | | Every callsite was passing an empty SymbolContext, so this parameter had no effect. Inside the DWARF implementation of this function, however, there was one codepath that checked members of the SymbolContext. Since no call-sites actually ever used this functionality, it was essentially dead code, so I've deleted this code path as well. llvm-svn: 351132
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-1416-63/+63
| | | | | | | | | | | | | This method took a SymbolContext but only actually cared about the case where the m_function member was set. Furthermore, it was intended to be implemented to parse blocks recursively despite not documenting this in its name. So we change the name to indicate that it should be recursive, while also limiting the function parameter to be a Function&. This lets the caller know what is required to use it, as well as letting new implementers know what kind of inputs they need to be prepared to handle. llvm-svn: 351131
* [lldbsuite] Skip two more flaky tests on WindowsStella Stamenova2019-01-142-0/+2
| | | | | | TestNamespaceLookup occasionally passes unexpectedly and TestExitDuringStep occasionally fails unexpectedly llvm-svn: 351080
* [Core] Use the implementation method GetAddressOf in ValueObjectConstResultChildAleksandr Urakov2019-01-143-0/+11
| | | | | | | | | | | | | | | | | | | | Summary: This patch allows to retrieve an address object for `ValueObject`'s children retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just uses the corresponding method of the implementation object `m_impl` to achieve that. Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille Reviewed By: clayborg Subscribers: leonid.mashinskiy, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56147 llvm-svn: 351065
* [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
* Add SymbolFileBreakpad.Jason Molenda2019-01-121-0/+15
| | | | llvm-svn: 350990
* [lldbsuite] Skip TestExitDuringStep on WindowsStella Stamenova2019-01-111-0/+1
| | | | | | This test is flaky on Windows and will occasionally hang or fail. llvm-svn: 350978
* Fix build breaks after the ParseCompileUnit changes.Zachary Turner2019-01-112-12/+9
| | | | | | | The addition of SymbolFileBreakpad crossed paths with my change, so this interface needs to be fixed up as well. llvm-svn: 350950
* 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] Include tests by default also in standalone buildsStefan Granitz2019-01-112-2/+2
| | | | | | In-tree builds include tests by default. Standalone builds should behave the same. llvm-svn: 350945
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-1119-319/+255
| | | | | | | | | | | | | | | | Previously all of these functions accepted a SymbolContext&. While a CompileUnit is one member of a SymbolContext, there are also many others, and by passing such a monolithic parameter in this way it makes the requirements and assumptions of the API unclear for both callers as well as implementors. All these methods need is a CompileUnit. By limiting the parameter type in this way, we simplify the code as well as make it self-documenting for both implementers and users. Differential Revision: https://reviews.llvm.org/D56564 llvm-svn: 350943
* [CMake] Remove dead code and outdated commentsStefan Granitz2019-01-113-23/+2
| | | | | | | | | | | | | | 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-1111-23/+482
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-112-1/+35
| | | | | | | | | | | | | | | | | | | | | 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
* Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.Zachary Turner2019-01-1014-52/+42
| | | | | | | | | | | | | | | | | | | | | | | | | The function SymbolFile::ParseTypes previously accepted a SymbolContext. This makes it extremely difficult to implement faithfully, because you have to account for all possible combinations of members being set in the SymbolContext. On the other hand, no clients of this function actually care about implementing this function to this strict of a standard. AFAICT, there is actually only 1 client in the entire codebase, and it is the function ParseAllDebugSymbols, which is itself only called for testing purposes when dumping information. At this call-site, the only field it sets is the CompileUnit, meaning that an implementer of a SymbolFile need not worry about any examining or handling any other fields which might be set. By restricting this API to accept exactly a CompileUnit& and nothing more, we can simplify the life of new SymbolFile plugin implementers by making it clear exactly what the necessary and sufficient set of functionality they need to implement is, while at the same time removing some dead code that tried to handle other types of SymbolContext fields that were never going to be set anyway. Differential Revision: https://reviews.llvm.org/D56462 llvm-svn: 350889
* [NativePDB] Add support for parsing typedef records.Zachary Turner2019-01-108-61/+349
| | | | | | | | | | | | | | | | | | | | 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
* lldbtest.py: try to fix a runtime exceptionAdrian Prantl2019-01-101-4/+7
| | | | | | found on http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/32/consoleFull#15046896708254eaf0-7326-4999-85b0-388101f2d404 llvm-svn: 350876
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-101-3/+0
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* Fix compilation error on 32-bit architectures introduced in r350511Pavel Labath2019-01-101-1/+1
| | | | | | | The issue was a narrowing conversion when converting from uint64_t to a size_t. llvm-svn: 350834
* Revert "Add a verbose mode to "image dump line-table" and use it to write a ↵Pavel Labath2019-01-102-119/+4
| | | | | | | | | | | | | .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-103-19/+66
| | | | | | | | | | | | | | | | | | 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-105-12/+50
| | | | | | | | | 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-102-4/+119
| | | | | | | | | | | | | | | | | | | | | | .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
* [Python] Update checkDsymForUUIDIsOn to be compatible with Python 3.Davide Italiano2019-01-101-4/+5
| | | | | | | | | | | | | | | | Summary: In python 2, strings and bytes are the same, but they're not in python 3, hence the return of read() needs an explicit conversion. While I'm around, rename the return of Popen() from `pipe` to `process`, as that's what Popen returns. Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56517 llvm-svn: 350788
* A little cleanup / commenting on locating kernel binaries while IJason Molenda2019-01-101-4/+18
| | | | | | | | | | was working on something else. DynamicLoaderDarwinKernel::SearchForKernelNearPC should have had an early return if the pc value is not in high memory; add that. The search for a kernel at 0x2000 offsets was a stopgap; it doesn't need to be checked any longer. llvm-svn: 350786
* [lldb-server] Add unnamed pipe support to PipeWindowsAaron Smith2019-01-109-42/+107
| | | | | | | | | | | | | | | | | Summary: This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process. Modify PipeWindows::CreateNew to support the creation of an unnamed pipe. Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed. Reviewers: zturner, llvm-commits Reviewed By: zturner Subscribers: Hui, labath, lldb-commits Differential Revision: https://reviews.llvm.org/D56234 llvm-svn: 350784
* 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