summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [Python] Update PyString_FromString() to work for python 2 and 3.Davide Italiano2019-01-092-10/+3
| | | | | | | | | | Reviewers: aprantl, JDevlieghere, friss, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56511 llvm-svn: 350769
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-095-60/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ParseDeclsForContext was originally created to serve the very specific case where the context is a function block. It was never intended to be used for arbitrary DeclContexts, however due to the generic name, the DWARF and PDB plugins implemented it in this way "just in case". Then, lldb-test came along and decided to use it in that way. Related to this, there are a set of functions in the SymbolFile class interface whose requirements and expectations are not documented. For example, if you call ParseCompileUnitFunctions, there's an inherent requirement that you create entries in the underlying clang AST for these functions as well as their signature types, because in order to create an lldb_private::Function object, you have to pass it a CompilerType for the parameter representing the signature. On the other hand, there is no similar requirement (either inherent or documented) if one were to call ParseDeclsForContext. Specifically, if one calls ParseDeclsForContext, and some variable declarations, types, and other things are added to the clang AST, is it necessary to create lldb::Variable, lldb::Type, etc objects representing them? Nobody knows. There is, however, an accidental requirement, because since all of the plugins implemented this just in case, lldb-test came along and used ParsedDeclsForContext, and then wrote check lines that depended on this. When I went to try and implemented the NativePDB reader, I did not adhere to this (in fact, from a layering perspective I went out of my way to avoid it), and as a result the existing DIA PDB tests don't work when the native PDB reader is enabled, because they expect that calling ParseDeclsForContext will modify the *module's* view of symbols, and not just the internal AST. All of this confusion, however, can be avoided if we simply stick to using ParseDeclsForContext for its original intended use case (blocks), and use a different function (ParseAllDebugSymbols) for its intended use case which is, unsuprisingly, to parse all the debug symbols (which is all lldb-test really wanted to do anyway). In the future, I would like to change ParseDeclsForContext to ParseDeclsForFunctionBlock, then delete all of the dead code inside that handles other types of DeclContexts (and probably even assert if the DeclContext is anything other than a block). A few PDB tests needed to be fixed up as a result of this, and this also exposed a couple of bugs in the DIA PDB reader (doesn't matter much since it should be going away soon, but worth mentioning) where the appropriate AST entries weren't being created always. Differential Revision: https://reviews.llvm.org/D56418 llvm-svn: 350764
* ELF: create "container" sections from PT_LOAD segmentsPavel Labath2019-01-0910-58/+488
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the result of the discussion in D55356, where it was suggested as a solution to representing the addresses that logically belong to a module in memory, but are not a part of any of its sections. The ELF PT_LOAD segments are similar to the MachO "load commands", except that the relationship between them and the object file sections is a bit weaker. While in the MachO case, the sections belonging to a specific segment are placed directly inside it in the object file logical structur, in the ELF case, the sections and segments form two separate hierarchies. This means that it is in theory possible to create an elf file where only a part of a section would belong to some segment (and another part to a different one). However, I am not aware of any tool which would produce such a file (and most tools will have problems ingesting them), so this means it is still possible to follow the MachO model and make sections children of the PT_LOAD segments. In case we run into (corrupt?) files with overlapping sections, I have added code (and tests) which adjusts the sizes and/or drops the offending sections in order to present a reasonable image to the upper layers of LLDB. This is mostly done for completeness, as I don't anticipate running into this situation in the real world. However, if we do run into it, and the current behavior is not suitable for some reason, we can implement this logic differently. Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D55998 llvm-svn: 350742
* [CMake] In standalone builds, LLVM_BINARY_DIR should point to LLVM's binary ↵Stefan Granitz2019-01-094-6/+4
| | | | | | | | | | | | | | | | directory Summary: In standalone builds `LLVM_BINARY_DIR` was equal to `LLDB_BINARY_DIR` so far. This is counterintuitive and invalidated the values of `LLDB_DEFAULT_TEST_DSYMUTIL/FILECHECK/COMPILER` etc. Reviewers: zturner, labath, clayborg, JDevlieghere, stella.stamenova, serge-sans-paille Reviewed By: labath Subscribers: mgorny, friss, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56443 llvm-svn: 350738
* [CMake] Fix standalone builds: workaround the cxx target not getting ↵Stefan Granitz2019-01-092-2/+14
| | | | | | | | | | | | | | | | imported yet (unlike clang target) Summary: Handle standalone builds separately and print a warning if we have no libcxx. Reviewers: aprantl, JDevlieghere Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D56399 llvm-svn: 350737
* [CMakeLists] Sort tools/CMakeLists.txtJonas Devlieghere2019-01-091-6/+8
| | | | llvm-svn: 350682
* Change std::sort to llvm::sort to detect non-determinism.Jonas Devlieghere2019-01-0817-44/+43
| | | | | | | | | | LLVM added wrappers to std::sort (r327219) that randomly shuffle the container before sorting. The goal is to uncover non-determinism due to undefined sorting order of objects having the same key. This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. llvm-svn: 350679
* Fix unused private field warning.Raphael Isemann2019-01-081-2/+3
| | | | | | | | | | Summary: The member is private and unused if HAVE_LIBCOMPRESSION is undefined, which triggers Clang's -Wunused-private-field warning. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56458 llvm-svn: 350675
OpenPOWER on IntegriCloud