summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* breakpad: Add FUNC records to the symtabPavel Labath2019-01-223-36/+112
| | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191193-4772/+3579
| | | | | | | | | | | | | | | | | 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
* Make sure to fill in the compiler register number so when we try to ↵Greg Clayton2019-01-182-15/+17
| | | | | | | | backtrace using EH frame, it works. Prior to this, backtraces could fail due to not being able to convert a EH frame register number to LLDB register number. llvm-svn: 351564
* Breakpad: Extract parsing code into a separate filePavel Labath2019-01-186-181/+395
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This centralizes parsing of breakpad records, which was previously spread out over ObjectFileBreakpad and SymbolFileBreakpad. For each record type X there is a separate breakpad::XRecord class, and an associated parse function. The classes just store the information in the breakpad records in a more accessible form. It is up to the users to determine what to do with that data. This separation also made it possible to write some targeted tests for the parsing code, which was previously unaccessible, so I write a couple of those too. Reviewers: clayborg, lemo, zturner Reviewed By: clayborg Subscribers: mgorny, fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D56844 llvm-svn: 351541
* Use llvm::VersionTuple instead of manual version marshallingBrad Smith2019-01-181-5/+6
| | | | llvm-svn: 351504
* [Reproducers] Refactor reproducer infoJonas Devlieghere2019-01-182-27/+26
| | | | | | | | | | | | | | | | | | | | | In the original reproducer design, I expected providers to be more dynamic than they turned out. For example, we don't have any instances where one provider has multiple files. Additionally, I expected there to be less locality between capture and replay, with the provider being defined in one place and the replay code to live in another. Both contributed to the design of the provider info. This patch refactors the reproducer info to be something static. This means less magic strings and better type checking. The new design still allows for the capture and replay code to live in different places as long as they both have access to the new statically defined info class. I didn't completely get rid of the index, because it is useful for (1) sanity checking and (2) knowing what files are used by the reproducer. Differential revision: https://reviews.llvm.org/D56814 llvm-svn: 351501
* Recommit "Teach the default symbol vendor to respect ↵Pavel Labath2019-01-171-5/+12
| | | | | | | | | | | | | | 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-4/+44
| | | | | | | | | | | 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-162-24/+29
| | | | | | | | | | | | 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
* Revert "Teach the default symbol vendor to respect ↵Pavel Labath2019-01-161-12/+5
| | | | | | | | 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-161-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-77/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Simplify Value::GetValueByteSize()Adrian Prantl2019-01-151-19/+15
| | | | llvm-svn: 351250
* Simplify codeAdrian Prantl2019-01-151-17/+21
| | | | llvm-svn: 351244
* 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-1534-525/+689
| | | | | | | | | | | | | | | | | | | | | | | 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-1424-122/+85
| | | | | | | | | | | | | | 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-1411-37/+15
| | | | | | | | | | | 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-1414-61/+61
| | | | | | | | | | | | | 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
* [Core] Use the implementation method GetAddressOf in ValueObjectConstResultChildAleksandr Urakov2019-01-141-0/+5
| | | | | | | | | | | | | | | | | | | | 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
* 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
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-1117-298/+237
| | | | | | | | | | | | | | | | 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
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-116-0/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | 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-1012-50/+40
| | | | | | | | | | | | | | | | | | | | | | | | | 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-106-61/+273
| | | | | | | | | | | | | | | | | | | | 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
* [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
* Revert "Add a verbose mode to "image dump line-table" and use it to write a ↵Pavel Labath2019-01-101-44/+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-102-19/+14
| | | | | | | | | | | | | | | | | | 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-10/+17
| | | | | | | | | 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-4/+44
| | | | | | | | | | | | | | | | | | | | | | .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
* 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-104-25/+69
| | | | | | | | | | | | | | | | | 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
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-092-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-56/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change std::sort to llvm::sort to detect non-determinism.Jonas Devlieghere2019-01-0816-43/+42
| | | | | | | | | | 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
* [BreakpointList] Simplify/modernize BreakpointList (NFC)Jonas Devlieghere2019-01-081-113/+56
| | | | | | | | | | | | | | | I was looking at the code in BreakpointList.cpp and found it deserved a quick cleanup. - Use std::vector instead of a std::list. - Extract duplicate code for notifying. - Remove code duplication when returning a const value. - Use range-based for loop. - Use early return in loops. Differential revision: https://reviews.llvm.org/D56425 llvm-svn: 350659
* [PdbAstBuilder] Remove unused functionsJonas Devlieghere2019-01-081-17/+0
| | | | | | | PdbAstBuilder.cpp:273:20: warning: unused function 'GetParentUniqueName' [-Wunused-function] PdbAstBuilder.cpp:267:13: warning: unused function 'IsUniqueNameEnumTag' [-Wunused-function] llvm-svn: 350652
* Convert to LLDB coding style (NFC)Adrian Prantl2019-01-081-7/+7
| | | | llvm-svn: 350651
* ProcessLaunchInfo: Remove Target referencePavel Labath2019-01-083-128/+113
| | | | | | | | | | | | | | | | | | | | | Summary: The target was being used in FinalizeFileActions to provide default values for stdin/out/err. Also, most of the logic of this function was very specific to how the lldb's Target class wants to launch processes, so I, move it to Target::FinalizeFileActions, inverting the dependency. The only piece of logic that was useful elsewhere (lldb-server) was the part which sets up a pty and relevant file actions. I've kept this part as ProcessLaunchInfo::SetUpPtyRedirection. This makes ProcessLaunchInfo independent of any high-level lldb constructs. Reviewers: zturner, jingham, teemperor Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56196 llvm-svn: 350617
* [SymbolContext] Remove dead codeJonas Devlieghere2019-01-081-55/+12
| | | | | | Removes two methods from SymbolContextList that aren't referenced. llvm-svn: 350599
* Simplify code.Adrian Prantl2019-01-071-2/+1
| | | | llvm-svn: 350577
* Clarify comment and variable names. (NFC)Adrian Prantl2019-01-071-5/+7
| | | | llvm-svn: 350576
OpenPOWER on IntegriCloud