summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] - Add support for DW_RLE_base_address and DW_RLE_offset_pair entries ↵George Rimar2018-10-245-54/+99
| | | | | | | | | | | (.debug_rnglists) The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair .debug_rnglists entries Differential revision: https://reviews.llvm.org/D53140 llvm-svn: 345127
* Support nwere versions of the Segger J-Link jtag board software.Jason Molenda2018-10-231-3/+12
| | | | | | | | | | | | | | | | | | | | | | Add support in ProcessGDBRemote::GetGDBServerRegisterInfo for recognizing a generic "arm" architecture that will be used if nothing better is available so that we don't ignore the register definitions if we didn't already have an architecture set. Also in ProcessGDBRemote::DoConnectRemote don't set the target arch unless we have a valid architecture to set it to. Platform::ConnectProcess will try to get the current target's architecture, or the default architecture, when creating the target for the connection to be attempted. If lldb was started with a target binary, we want to create this target with that architecture in case the remote gdb stub doesn't supply a qHostInfo arch. Add logging to Target::MergeArchitecture. <rdar://problem/34916465> llvm-svn: 345106
* Remove unused private methods.Zachary Turner2018-10-231-8/+0
| | | | llvm-svn: 345092
* Fix some comments pointed out by Leonard Mosescu.Zachary Turner2018-10-231-4/+4
| | | | | | | These were originally pointed out in D53511 but I forgot to incorporate them in my patch. llvm-svn: 345091
* Remove unused variable.Eric Christopher2018-10-231-1/+0
| | | | llvm-svn: 345086
* Change two methods from const char* to StringRef [NFC].Zachary Turner2018-10-232-5/+3
| | | | llvm-svn: 345055
* [NativePDB] Add basic support for tag types to the native pdb plugin.Zachary Turner2018-10-236-3/+1002
| | | | | | | | | | | | | | | | | This adds support to LLDB for named types (class, struct, union, and enum). This is true cross platform support, and hits the PDB file directly without a dependency on Windows. Tests are added which compile a program with certain interesting types and then use load the target in LLDB and use "type lookup -- <TypeName>" to dump the layout of the type in LLDB without a running process. Currently only fields are parsed -- we do not parse methods. Also we don't deal with bitfields or virtual bases correctly. Those will make good followups. Differential Revision: https://reviews.llvm.org/D53511 llvm-svn: 345047
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-237-4/+35
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* [PDB] Improve performance of the PDB DIA pluginAleksandr Urakov2018-10-232-25/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves performance of `SymbolFilePDB` on huge executables in two ways: - cache names of public symbols by address. When creating variables we are trying to get a mangled name for each one, and in `GetMangledForPDBData` we are enumerating all public symbols, which takes O(n) for each variable. With the cache we can retrieve a mangled name in O(log(n)); - cache section contributions. When parsing variables for context we are enumerating all variables and check if the current one is belonging to the current compiland. So we are retrieving a compiland ID for the variable. But in `PDBSymbolData::getCompilandId` for almost every variable we are enumerating all section contributions to check if the variable is belonging to it, and get a compiland ID from the section contribution if so. It takes O(n) for each variable, but with caching it takes about O(log(n)). I've placed the cache in `SymbolFilePDB` and have created `GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId` except for the cache part. Another option is to support caching in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it seems that the last one doesn't imply such functionality, because it's a lightweight wrapper over DIA and whole its state is only a COM pointer to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only inside of `SymbolFilePDB`, so I think that it's not a bad place to do such things. With this patch `PDBSymbolData::getCompilandId` is not used at all. This bottlenecks were found with profiling. I've discovered these on a simple demo project of Unreal Engine (x86 executable ~72M, PDB ~82M). This patch doesn't change external behavior of the plugin, so I think that there's no need for additional testing (already existing tests should warn us about regress, if any). Reviewers: zturner, asmith, labath Reviewed By: asmith Subscribers: Hui, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53375 llvm-svn: 345013
* [SymbolFile] Add the module lock where necessary and assert that we own it.Jonas Devlieghere2018-10-222-4/+45
| | | | | | | | | | | | | | | As discussed with Greg at the dev meeting, we need to ensure we have the module lock in the SymbolFile. Usually the symbol file is accessed through the symbol vendor which ensures that the necessary locks are taken. However, there are a few methods that are accessed by the expression parser and were lacking the lock. This patch adds the locking where necessary and everywhere else asserts that we actually already own the lock. Differential revision: https://reviews.llvm.org/D52543 llvm-svn: 344945
* Some cleanups to the native pdb plugin [NFC].Zachary Turner2018-10-225-130/+244
| | | | | | | | | | | This is mostly some cleanup done in the process of implementing some basic support for types. I tried to split up the patch a bit to get some of the NFC portion of the patch out into a separate commit, and this is the result of that. It moves some code around, deletes some spurious namespace qualifications, removes some unnecessary header includes, forward declarations, etc. llvm-svn: 344913
* [SymbolFileNativePDB] Fix missing linkage to DebugInfoCodeViewMichal Gorny2018-10-181-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D53402 llvm-svn: 344746
* Revert "Return a named error in the result object of an expression with no ↵Krasimir Georgiev2018-10-181-1/+1
| | | | | | | | | | | | | | | | | result" This reverts commit r344647. This causes build failures with [-Werror, -Wswitch]. Some cases where the newly introduced enum value is not handled in particular are in: lldb/source/Expression/REPL.cpp:350 lldb/source/Interpreter/CommandInterpreter.cpp:1529 (maybe there could be more) As I don't understand lldb to make sure the likely trivial fixes are correct and also as they might need additional tests, leaving to the author to resolve. llvm-svn: 344722
* [LLDB] - Add support for DW_RLE_start_end entries (.debug_rnglists)George Rimar2018-10-171-1/+8
| | | | | | | | | | | | | | | DWARF5 describes DW_RLE_start_end as: This is a form of bounded range entry that has two target address operands. Each operand is the same size as used in DW_FORM_addr. These indicate the starting and ending addresses, respectively, that define the address range for which the following location is valid. The patch implements the support. Differential revision: https://reviews.llvm.org/D53193 llvm-svn: 344674
* Return a named error in the result object of an expression with no resultJim Ingham2018-10-161-1/+1
| | | | | | | | | | | | Before we returned an error that was not exposed in the SB API and no useful error message. This change returns eExpressionProducedNoResult and an appropriate error string. <rdar://problem/44539514> Differential Revision: https://reviews.llvm.org/D53309 llvm-svn: 344647
* Code cleanup: Remove DWARFDebugInfoEntry::m_empty_childrenJan Kratochvil2018-10-163-22/+14
| | | | | | | | | | | | | | | | | | | | | | | It merges DWARFDebugInfoEntry's m_empty_children into m_has_children. m_empty_children was implemented by rL144983. As Greg confirmed m_has_children was used to represent what was in the DWARF in the byte that follows the DW_TAG. m_empty_children was used for DIEs that said they had children but actually only contain a single NULL tag. It is fine to not differentiate between the two. Also changed assert()->lldbassert() for m_abbr_idx 16-bit overflow check as that could be a tough bug to catch if it ever happens. I have checked all calls of HasChildren() that this change should not matter to them. The code even wants to know if there are any children - it does not matter how the children presence is coded in the binary. Patch written based on suggestions by Greg Clayton. Differential Revision: https://reviews.llvm.org/D53321 llvm-svn: 344644
* For a built & test bot, add an environment variable PLATFORM_SDK_DIRECTORY,Jason Molenda2018-10-161-0/+23
| | | | | | | | | | | which PlatformRemoteDarwinDevice::UpdateSDKDirectoryInfosIfNeeded which examine for any additional SDK directories when it is constructing its list. <rdar://problem/42984340> <rdar://problem/41351223> llvm-svn: 344628
* Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), ↵Jan Kratochvil2018-10-161-1/+5
| | | | | | | | | | | | | | | | function ExtractDIEsRWLocked xbolva00 bugreported $subj in: https://reviews.llvm.org/D46810#1247410 It can happen only from the line: m_die_array.back().SetEmptyChildren(true); In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of list, no children present). Therefore the assertion can fortunately happen only with a hand-crafted DWARF or with DWARF from some suboptimal compilers. Differential Revision: https://reviews.llvm.org/D53255 llvm-svn: 344605
* Convert code to use early exits in prepraration for future changes. (NFC)Adrian Prantl2018-10-151-56/+56
| | | | llvm-svn: 344557
* Fix double import of _lldb module.Vadim Chugunov2018-10-141-0/+3
| | | | | | | | | | | | Fix llvm.org/pr39054: - Register _lldb as a built-in module during initialization of script interpreter, - Reverse the order of imports in __init__.py: first try to import by absolute name, which will find the built-in module in the context of lldb (and other hosts that embed liblldb), then try relative import, in case the module is being imported from Python interpreter. This works for SWIG>=3.0.11; before that, SWIG did not support custom module import code. Differential revision: https://reviews.llvm.org/D52404 llvm-svn: 344474
* Try to fix some failures on MacOSX with the NativePDB patch.Zachary Turner2018-10-121-2/+9
| | | | | | | | | | This adds -- before any filenames, so that /U doesn't get interpreted as a command line. It also adds better error checking, so that we don't get assertions on the failure path when a file fails to parse as a PDB. llvm-svn: 344429
* Resubmit "Add SymbolFileNativePDB plugin."Zachary Turner2018-10-1213-4/+2049
| | | | | | | | | | This was originally reverted due to some test failures on Linux. Those problems turned out to require several additional patches to lld and clang in order to fix, which have since been submitted. This patch is resubmitted unchanged. All tests now pass on both Linux and Windows. llvm-svn: 344409
* [LLDB] - Add support for DW_FORM_implicit_const.George Rimar2018-10-128-51/+63
| | | | | | | | | | | | | | | LLDB does not support this DWARF5 form atm. At least gcc emits it in some cases when doing optimization for abbreviations. As far I can tell, clang does not support it yet, though the rest LLVM code already knows about it. The patch adds the support. Differential revision: https://reviews.llvm.org/D52689 llvm-svn: 344328
* Revert SymbolFileNativePDB plugin.Zachary Turner2018-10-1113-2049/+4
| | | | | | | | | This was originally causing some test failures on non-Windows platforms, which required fixes in the compiler and linker. After those fixes, however, other tests started failing. Reverting temporarily until I can address everything. llvm-svn: 344279
* Fix this comment so it is consistent with all the others.Jason Molenda2018-10-111-1/+1
| | | | llvm-svn: 344277
* Don't mark an LC_BUILD_VERSION as giving us a Jason Molenda2018-10-111-1/+1
| | | | | | correct version if it has a major verison 0. llvm-svn: 344275
* Better support for POSIX paths in PDBs.Zachary Turner2018-10-112-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | While it doesn't make a *ton* of sense for POSIX paths to be in PDBs, it's possible to occur in real scenarios involving cross compilation. The tools need to be able to handle this, because certain types of debugging scenarios are possible without a running process and so don't necessarily require you to be on a Windows system. These include post-mortem debugging and binary forensics (e.g. using a debugger to disassemble functions and examine symbols without running the process). There's changes in clang, LLD, and lldb in this patch. After this the cross-platform disassembly and source-list tests pass on Linux. Furthermore, the behavior of LLD can now be summarized by a much simpler rule than before: Unless you specify /pdbsourcepath and /pdbaltpath, the PDB ends up with paths that are valid within the context of the machine that the link is performed on. Differential Revision: https://reviews.llvm.org/D53149 llvm-svn: 344269
* [lldb] Surpress copy-elison warning.Eric Liu2018-10-111-2/+2
| | | | llvm-svn: 344252
* [lldb] rename MinOS::minor to MinOS::minor_version etc. NFCEric Liu2018-10-111-8/+8
| | | | | | | The constructor initializer minor(...)/major(...) can be confused with system macros `#define minor(...)` on some platforms. llvm-svn: 344250
* Upstreaming the BridgeOS device support and the Jason Molenda2018-10-1113-26/+457
| | | | | | | | | | | | | | | LC_BUILD_VERSION load command handling - this commit is a combination of patches by Adrian Prantl and myself. llvm::Triple::BridgeOS isn't defined yet, so all references to that are currently commented out. Also update Xcode project file to build the NativePDB etc plugins. <rdar://problem/43353615> llvm-svn: 344209
* [SymbolFileNativePDB] Fix compilation errors with gcc.Zachary Turner2018-10-104-6/+11
| | | | llvm-svn: 344173
* [Windows] Fix a bug that causes lldb to freezeAaron Smith2018-10-102-5/+15
| | | | | | | | | | | | | | | | | | | | | Summary: If the process exits before any initial stop then notify the debugger of the error otherwise WaitForDebuggerConnection() will be blocked. An example of this issue is when a process fails to load a dependent DLL. In addition to the fix, remove a duplicate call to FreeProcessHandles() in DebuggerThread::HandleExitProcessEvent() and use decimal format for all thread IDs. Reviewers: rnk, zturner, aleksandr.urakov Reviewed By: zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D53090 llvm-svn: 344168
* Create a SymbolFile plugin for cross-platform PDB access.Zachary Turner2018-10-1013-4/+2044
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing SymbolFilePDB only works on Windows, as it is written against a closed-source Microsoft SDK that ships with their debugging tools. There are several reasons we want to bypass this and go straight to the bits of the PDB, but just to list a few: More room for optimization. We can't see inside the implementation of the Microsoft SDK, so we don't always know if we're doing things in the most efficient way possible. For example, setting a breakpoint on main of a big program currently takes several seconds. With the implementation here, the time is unnoticeable. We want to be able to symbolize Windows minidumps even if not on Windows. Someone should be able to debug Windows minidumps as if they were on Windows, given that no running process is necessary. This patch is a very crude first attempt at filling out some of the basic pieces. I've implemented FindFunctions, ParseCompileUnitLineTable, and ResolveSymbolContext for a limited subset of possible parameter values, which is just enough to get it to display something nice for the breakpoint location. I've added several tests exercising this functionality which are limited enough to work on all platforms but still exercise this functionality. I'll try to add as many tests of this nature as I can, but at some point we'll need a live process. For now, this plugin is enabled always on non-Windows, and by setting the environment variable LLDB_USE_NATIVE_PDB_READER=1 on Windows. Eventually, once it's at parity with the Windows implementation, we'll delete the Windows DIA-based implementation. Differential Revision: https://reviews.llvm.org/D53002 llvm-svn: 344154
* [LLDB] - Simplify. NFC.George Rimar2018-10-101-8/+1
| | | | | | | | | | There are several places that call `FindRanges`, all of them use `Slide` to adjust the ranges found by the base address. All except one, which does the same manually in a loop. Patch updates it to use `Slide` for consistency. llvm-svn: 344122
* [LLDB] - Add basic support for .debug_rnglists section (DWARF5)George Rimar2018-10-107-13/+110
| | | | | | | | | This adds a basic support of the .debug_rnglists section. Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported. Differential revision: https://reviews.llvm.org/D52981 llvm-svn: 344119
* Add support for artificial tail call framesVedant Kumar2018-10-054-0/+68
| | | | | | | | | | | | | | | | This patch teaches lldb to detect when there are missing frames in a backtrace due to a sequence of tail calls, and to fill in the backtrace with artificial tail call frames when this happens. This is only done when the execution history can be determined from the call graph and from the return PC addresses of calls on the stack. Ambiguous sequences of tail calls (e.g anything involving tail calls and recursion) are detected and ignored. Depends on D49887. Differential Revision: https://reviews.llvm.org/D50478 llvm-svn: 343900
* Fix typos.Bruce Mitchener2018-10-044-7/+7
| | | | | | | | | | Reviewers: lldb-commits Subscribers: srhines, ki.stfu Differential Revision: https://reviews.llvm.org/D52884 llvm-svn: 343825
* Pull FixupBreakpointPCAsNeeded into base classPavel Labath2018-10-034-153/+1
| | | | | | | | | | | | | | | | | Summary: This function existed (with identical code) in both NativeProcessLinux and NativeProcessNetBSD, and it is likely that it would be useful to any future implementation of NativeProcessProtocol. Therefore I move it to the base class. Reviewers: krytarowski Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52719 llvm-svn: 343683
* DWARFExpression: Resolve file addresses in the linked moduleAdrian Prantl2018-10-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow-up to https://reviews.llvm.org/D46362. When evaluating a complex expression in DWARFExpression::Evaluate, file addresses must be resolved to load addresses before we can perform operations such as DW_OP_deref on them. For this the address goes through three steps 1. Read the file address as stored in the DWARF 2. Link/relocate the file address (when reading from a .dSYM, this is a no-op) 3. Convert the file address to a load address. D46362 implemented step (3) by resolving the file address using the Module that the original DWARF came from. In the case of a dSYM that is correct, but when reading from .o files, we need to look up relocated/linked addresses, so the right place to look them up is the current frame's module. This patch fixes that by setting the expression's Module to point to the linked debugmap object. A word a bout the unorthodox testcase: The motivating testcase for this fix is in Swift, but I managed to hand-modify LLVM-IR for a trivial C program to exhibit the same problem, so we can fix this in llvm.org. rdar://problem/44689915 Differential Revision: https://reviews.llvm.org/D52678 llvm-svn: 343612
* Fix NetBSD build for r343409Pavel Labath2018-09-301-1/+0
| | | | | | Forgot to remove the method declaration from the header. llvm-svn: 343411
* Pull GetSoftwareBreakpointPCOffset into base classPavel Labath2018-09-303-65/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: This function encodes the knowledge of whether the PC points to the breakpoint instruction of the one following it after the breakpoint is "hit". This behavior mainly(*) depends on the architecture and not on the OS, so it makes sense for it to be implemented in the base class, where it can be shared between different implementations (Linux and NetBSD atm). (*) It is possible for an OS to expose a different API, perhaps by doing some fixups in the kernel. In this case, the implementation can override this function to implement custom behavior. Reviewers: krytarowski, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52532 llvm-svn: 343409
* Revert r343318 together with llvm commit r343317Luke Cheeseman2018-09-282-3/+3
| | | | llvm-svn: 343342
* Reapply the changes reverted by r343236Luke Cheeseman2018-09-282-3/+3
| | | | llvm-svn: 343318
* [PDB] Handle `char` as a builtin typeAleksandr Urakov2018-09-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `char`, `signed char` and `unsigned char` are three different types, and they are mangled differently: ``` void __declspec(dllexport) /* ?foo@@YAXD@Z */ foo(char c) { } void __declspec(dllexport) /* ?foo@@YAXE@Z */ foo(unsigned char c) { } void __declspec(dllexport) /* ?foo@@YAXC@Z */ foo(signed char c) { } ``` This commit separates `char` from `signed char` and `unsigned char`. Reviewers: asmith, zturner, labath Reviewed By: asmith, zturner Subscribers: teemperor, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D52468 llvm-svn: 343298
* Revert r343193 together with r343192Luke Cheeseman2018-09-272-3/+3
| | | | llvm-svn: 343236
* Update CallFrameString API to account for r343114Luke Cheeseman2018-09-272-3/+3
| | | | | | | - CallFrameString now takes an Arch parameter to account for multiplexing overlapping CFI directives llvm-svn: 343193
* Refactor ClangUserExpression::GetLanguageForExprRaphael Isemann2018-09-272-20/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `ClangUserExpression::GetLanguageForExpr` method is currently a big source of sadness, as it's name implies that it's an accessor method, but it actually is also initializing some variables that we need for parsing. This caused that we currently call this getter just for it's side effects while ignoring it's return value, which is confusing for the reader. This patch renames it to `UpdateLanguageForExpr` and merges all calls to the method into a single call in `ClangUserExpression::PrepareForParsing` (as calling this method is anyway mandatory for parsing to succeed) While looking at the code, I also found that we actually have two language variables in this class hierarchy. The normal `Language` from the UserExpression class and the `LanguageForExpr` that we implemented in this subclass. Both don't seem to actually contain the same value, so we probably should look at this next. Reviewers: xbolva00 Reviewed By: xbolva00 Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D52561 llvm-svn: 343191
* Replace pointer to C-array of PropertyDefinition with llvm::ArrayRefTatyana Krasnukha2018-09-278-20/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D52572 llvm-svn: 343181
* Fix ProcessKDP after r343130Tatyana Krasnukha2018-09-261-2/+2
| | | | llvm-svn: 343141
* Fix OSX build after r343130Tatyana Krasnukha2018-09-261-3/+3
| | | | llvm-svn: 343134
OpenPOWER on IntegriCloud